Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Authentication

Participating partners will be obligated to provide external URL(s) for the service utilizing SSO.  These will be granted as part of the certification process and added to the application for allowing access.

How It Works

The SSO functionality that is built into AlloraCRM™ is designed to allow 3rd party sites to integrate guest login capabilities for use within the hoteliers website or mobile App and for a seamless transition between sites such as Booking Engine, Content Website and Guest Portal. Single Sign On (SSO) is compliant with OpenID Connect, using a standard Authorization Code Flow with PKCE and the associated tool is built using .net MVC as sample client application. However the client can be build using any OAuth Client SDK for your technology stack using the Authorization Code Flow with PKCE.

General Flow

  1. The user clicks Login within the application.

  2. Your OAuth Client SDK creates a cryptographically-random code_verifier and from this generates a code_challenge.

  3. Your OAuth Client SDK redirects the user to the AlloraCRM™ Identity Server (/authorize endpoint) along with the code_challenge.

  4. The AlloraCRM™ Identity Server redirects the user to the login and authorization prompt.

  5. The user authenticates using one of the configured login options and may see a consent page listing the permissions Your OAuth Client SDK will give to the application.

  6. The AlloraCRM™ Identity Server stores the code_challenge and redirects the user back to the application with an authorization code, which is good for one use.

  7. Your OAuth Client SDK sends this code and the code_verifier (created in step 2) to the AlloraCRM™ Identity Server (/token endpoint).

  8. The AlloraCRM™ Identity Server verifies the code_challenge and code_verifier.

  9. The AlloraCRM™ Identity Server responds with an ID Token and Access Token.

  10. The ID Token contains a custom claim for AlloraCRM™ playerID

  11. Your application can use the playerID and the Access Token to call AlloraCRM™ API(s) to access information about the user.

  12. The API responds with requested data.

Sample MVC Application

Initial view before Guest logs in:

View after Guest logs in:

Profile information page:

The sample code for the application described above can be found here.

 

  • No labels