This is part of a larger series on OAuth 2.0 Threats. The other parts are linked below.
- OAuth 2.0 Threat Model and Security Considerations
- OAuth 2.0 Client Threats
- OAuth 2.0 Authorisation Endpoint Threats
- OAuth 2.0 Token Endpoint Threats
- OAuth 2.0 Refresh Token Threats
- OAuth 2.0 Protected Resource Threats
The Client. In OAUTH2 terminology this is the part that is asking for Authorisation. It might be a web client directly. It might be a web client via a backend server. It might be a server on its own. When OAuth 2.0 was envisaged the web clients were more ‘smart forms’ engines, e.g. the backend had all the rendering smarts in something like PHP and there was no Angular Typescript Single Page Applications.
As a consequence, the initial architecture envisaged a secret that could be protected, something running on that web server which did the authorisation on behalf of a user. Some implementations started to experiment with a web client directly talking to the OAuth 2.0 server, and the Implicit flow was born. The Implicit flow in turn ended up fairly weak and the PKCE flow was born. If you are writing a new Web Application today you should use the PKCE flow. If you have an existing application using the Implicit flow, make sure you understand your Content-Security-Policy and your upstream code base is well trusted, else you should update.
NEVER EVER ISSUE A CLIENT SECRET TO A WEB CLIENT. There is no way to do this safely.
If you have an implementation where the backend server is resonsible for Authorising the user, make sure it has a secure means of storing the Client Secret, and, consider rotating that secret (with revocation).
A threat that is often overlooked on the Client is the refresh token. The Refresh Token can be used to obtain new Access Tokens, so losing it can be problematic. To reduce this risk, make sure your clients use specific scopes, and, the minimum set they can. Verify the client id on the refresh. And consider refresh token rotation.
An Access Token (typically a JWT) is “you-in-a-string”. So clearly you want to ensure the client does not leak this to unauthorised parties. Clients have a bad history of storing these in shared persistent storage. Mitigation includes limiting the duration, auditing applications to ensure they use similar protection as for refresh tokens.
A common client model which emerged was a mobile application which used an embedded browser for the OAuth 2.0 phase. This has been deprecated and many providers no longer support it. The risk is a malicious application phishing a user, owning the embedded browser, getting a cleartext copy of the users authentication information.
As always, employ Defense In Depth, employ Zero Trust. The client may be part of your security solution, but it can never be considered secure. Secure it using best practices, and then move on with the assumption it is compromised.