Authentication

CSI Auth authenticates users with OpenID Connect on top of Auth0. This page covers the flow your app follows to sign a user in and the tokens that come out of it. It doesn’t cover service-to-service calls; for those, see M2M requirements and best practices.

The flow

Every app type, browser-based, server-rendered, or native, uses authorization code with PKCE:

1. Your app redirects the user to the CSI Auth login page
2. The user authenticates, against a database, social, or enterprise connection
3. CSI Auth redirects back to your app with an authorization code
4. Your app exchanges the code for tokens

The exact steps for wiring this into your framework are in the implementation guide for your app type; this page covers the concepts those guides assume.

What you get back

See Access vs ID tokens for how to use each one, and Tokens and sessions for how long they last and what to do when one expires.

Authorizing a signed-in user

The access token’s scopes come from the roles assigned to the user. See Roles and permissions for how a permission ends up in a token, and Scopes, permissions, and tokens for enforcing it in your app.

Ending a session

See Logout for clearing both CSI Auth’s session and your app’s.