Clients

A client (aka relying party or RP) is a piece of software that requests tokens from IdentityServer - either for authenticating a user (requesting an identity token) or for accessing a resource (requesting an access token). A client must be first registered with IdentityServer before it can request tokens.

Examples for clients are web applications, native mobile or desktop applications, SPAs, server processes etc.

Registration requirements vary depending on the type of client before being able to request tokens.

Current typical configuration requirements for settings within the OP for a:

Client for Server to Server Communication

  • A unique client_id
  • A secret (obtain from CRMLS admin).
  • Client credentials grant/flow type
  • The scopes (aka resources) client requires access to (arrange with CRMLS admin).

Legacy Client with End User(s)

Browser-based Client (e.g., SPA)

  • A unique client_id
  • Implicit grant/flow type
  • A callback/redirect URI (redirect_uri) or list of URIs.
  • The scopes (arrange with CRMLS admin).
  • Optional post logout URI(s).

Implicit flow is the recommended flow for client applications that involve end users.

Implicit Flow properties

  • All tokens returned from authorization endpoint (no need for token endpoint)
  • Tokens revealed to User Agent
  • Communication in one round trip

Example client side settings (javascript - CRMLS OP client registered with implicit grant type)

function getClientSettings(): UserManagerSettings {
  return {
    authority: 'https://soc.crmls.org/',
    client_id: 'js_oidc',
    redirect_uri: 'http://sample.client.com/auth-callback',
    post_logout_redirect_uri: 'http://sample.client.com/',
    response_type: "id_token token",
    acr_values: "idp:Saml2",
    scope: "openid profile CrmlsProfile webapi",
    filterProtocolClaims: true,
    checkSessionInterval: 2000,
    // automaticSilentRenew: true, 
    loadUserInfo: true
  };
}

Basic Client Workflow (Implicit Flow)

The sequence below depicts a simple, 'happy path' scenario for an end user accessing CRMLS ODataApi (including logging in).

sequenceDiagram participant Web Browser participant Client App participant ODataApi participant CRMLS OP Web Browser->>Client App: 1 - Request protected page Client App->>Web Browser: 2 - Redirect to Login page Web Browser->>CRMLS OP: 3 - GET and POST Login page CRMLS OP->>Web Browser: 4 - Login success - redirect to protected page Web Browser->>Client App: 5 - Request to redirected protected page Client App->>Web Browser: 6 - Response with protected page Web Browser->>ODataApi: 7 - Request protected resource ODataApi->>CRMLS OP: 8 - Validate token CRMLS OP->>ODataApi: 9 - Validated response ODataApi->>ODataApi: 10 - Cache validated token ODataApi->>Web Browser: 11 - Reponse with protected resource results

Walk through of the sequence:

  1. User opens a web browser and goes to a protected page on “Client App” (or Third Party Web App).
  2. No previous session metadata exists and therefore user’s browser is redirected to a ‘Login page’.
  3. The browser requests for Login page (NB: skipped showing receipt of Login page) – And user provides login credentials and submits.
  4. CRMLS OP processes the login and responds with success, a redirect to the requested page, and relevant tokens (i.e., id_token and access_token) along with scope and claims belonging to the logged in user for the application – “Client App”.
  5. The browser requests for the protected page.
  6. Browser receives the protected page.
  7. Browser now requests a protected resource (e.g., due to ajax call from protected page) with reference token (access_token) and session state metadata.
  8. “ODataApi” checks session (and cache) then reaches to CRMLS OP to validate reference token.
  9. Validation is successful, and response includes user identity and resource attributes that are configured for “ODataApi” to receive.
  10. “ODataApi” stores/caches validated reference token (life span of cache * ~ 60 minutes - adjustable).
  11. Browser receives results from requested (ODataApi) resource.

* Clients are responsible to check sessions and/or tokens that are stale and redirect appropriately based on the application: e.g., back to the Login URL or similar.

References/Help