Interactive Clients

This is the most common type of client scenario: web applications, SPAs or native/mobile apps with interactive users.

For this type of clients, the authorization code flow was designed. That flow consists of two physical operations:

  • A front-channel step via the browser where all “interactive” things happen, e.g. login page, consent etc. This step results in an authorization code that represents the outcome of the front-channel operation.

  • A back-channel step where the authorization code from step 1 gets exchanged with the requested tokens. Confidential clients need to authenticate at this point.

In more details:

  1. When the user tries to access the client application, client application makes a GET request to the authorize endpoint.

  2. As a result, user receives the login screen on our identity provider where they need to enter their credentials.

  3. After successful verification of the credentials, user is redirected to the predefined client redirect URL and at this point client application captures the authorization code from the URL parameter.

  4. An authorization code cannot be used to call API endpoints. It is used to make a POST request to get an access token. For confidential clients this call does not go through the user’s browser. It is direct communication between client’s back-end and the identity provider.

  5. Response of the previous call will be a JSON payload with the access token that can be used to call the KS Connect API.

This flow has the following security properties:

  • No data (besides the authorization code which is basically a random string) gets leaked over the browser channel

  • Authorization codes can only be used once

  • For confidential clients the authorization code can only be turned into tokens when the client secret is known

  • Public clients do not use client secret in this flow (since public clients can’t securely store such secret)

For more information about public and confidential clients refer to Application Types.

Authorization code flow should be used together with PKCE to avoid “code substitution attacks“. PKCE is already the official recommendation for native applications and SPAs.

Step by Step walk-through for Authorization Code flow can be found here.

REFRESH TOKENS

If the GET request in step 1 contains the scope offline_access, response in step 5 will, besides the access token, also include a refresh token.

https://identity-server-url/connect/authorize?response_type=code&scope=user_api.full_access+offline_access&client_id={{client_id}}&redirect_uri={{redirect_uri}}

Because a refresh token has a much longer lifetime it can be used to obtain another access token with a POST call to the token endpoint.

POST connect/token
Content-Type: application/x-www-form-urlencoded 
Authorization: Basic {{access_token}}
grant_type=refresh_token&refresh_token={{refresh_token}}


Next

App storePlay store