# OAuth 2.0 Client Threats

- Link: https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations-1/
- Published: 2021-01-08T06:00:00+00:00
- Author: Don Bowman

This is part of a larger [series](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations)
on OAuth 2.0 Threats. The other parts are linked below.

 1. [OAuth 2.0 Threat Model and Security Considerations](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations/)
 2. [OAuth 2.0 Client Threats](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations-1)
 3. [OAuth 2.0 Authorisation Endpoint Threats](https://www.agilicus.com/oauth-2-0-authorisation-endpoint-threats/)
 4. [OAuth 2.0 Token Endpoint Threats](https://www.agilicus.com/oauth-2-0-token-endpoint-threats/)
 5. [OAuth 2.0 Refresh Token Threats](https://www.agilicus.com/oauth-2-0-refresh-token-threats/)
 6. [OAuth 2.0 Protected Resource Threats](https://www.agilicus.com/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](https://www.php.net/) 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](https://tools.ietf.org/html/rfc7636) 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](https://www.agilicus.com/web-security-101-2/) 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](https://www.agilicus.com/jwt-token-is-you-on-the-wire/))
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](https://www.agilicus.com/firewall-defense-in-depth/),
employ [Zero Trust](https://zero-trust.ca/). 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.