Skip to content

Latest commit

 

History

History
22 lines (14 loc) · 3.04 KB

client-recommendations.md

File metadata and controls

22 lines (14 loc) · 3.04 KB
Raw

Recommendations for implementing Layman's client

Any Layman's client (web, user-agent, mobile, or desktop) that implements OAuth2 authentication should implement all responsibilities of Layman Test Client (LTC). As there are many ways how to accomplish it, this page provides some recommendations.

Appropriate Code Grant

OAuth2 specifies many ways how to authorize client and how client obtains access and refresh tokens. These ways are called authorization grants. For LTC, the Authorization Code grant was chosen. For native clients (desktop and mobile), as well as for user agent applications, Authorization Code with PKCE (RFC7636) is recommended.

Both Authorization Code and Authorization Code with PKCE grant flows between client and authorization server are described in Django OAuth Toolkit documentation.

Storing Tokens on a Client

An important decision when implementing OAuth2 client is where to store access tokens and refresh tokens. The recommendations differ based on client profile.

Web Applications are able to store tokens either on server side or client side. There exists quite straightforward recommendations (see e.g. auth0, DZone or StackExchange). Generally three options are available:

  1. Store access tokens in browser memory. It would mean to provide new authorization request against authorization server and manual end-user authorization consent on every page open or page reload.
  2. Store access tokens in both secure and HTTP-only cookies. This option requires to have server side to set access tokens in cookies, and to refresh them using refresh tokens. Also refresh tokens need to be saved on server side.
  3. Store access token on server side in any well-protected database.

Because option 1 is totally impractical and both options 2 and 3 require server side, it was decided to implement option 3 in LTC as the most secure one (it does not expose access token to client/browser at all).

User Agent Applications are potentially the most dangerous ones. As described in Web Applications section, storing tokens in memory is impractical, and other options require server side, so user agent application actually becomes Web Application.

Native Applications (i.e. desktop or mobile) should store tokens in any well-protected database.