As far as I understand, Authorization code with PKCE is suitable for public client. Let's say I have two client_id here user and staff, User only has 'read' scope while Staff has 'write' and 'read'.
Imagine in a situation where an expert user trying to impersonate as a staff so he changed client_id from user to staff and generated his own code_verifier and hashed with sha-256. After he logged-in successfully with his username/password and client_id=staff now he can request for an access_token with his generated code_verifier and gain 'write' and 'read' scope. I think that should be possible to do right since PKCE doesnt require client_secret so you can use any client_id that you want.
if that's so how can I secure my staff client, I have two login pages one for the user and another one for staff both are public client.
CodePudding user response：
API AUTHORIZATION
The main problem here is relying solely on scopes for authorization. Your example write scope means this:
- Grants write privileges to the client, when the user qualifies
The main authorization in any real world system should be done based on claims issued to the access token.
In your example this might be represented by a claim such as role=user. Or perhaps authorization could derive from the token's subject claim. After authentication, when the access token is sent to an API, a 403 would be returned for the user who changed their client ID, since to he API might require a staff role.
WEB AND MOBILE CLIENTS
If the client is a web app, then using a backend for frontend would help to prevent authentication for the wrong app, due to a client secret being attached by the BFF.
For mobile clients, there is an emerging trend for the app to use its Apple or Google signing key as a proof, to attest its identity, before authentication can begin, This is not mainstream yet though, so you may not be able to use it.
SUMMARY
Consider OAuth flows that prevent client impersonation. Always authorize based on the user identity, to prevent escalation of privilege attacks.