ODataOP

OpenID Connect Authenticate Service for OData API (aka: ODataOP)

This authenticate service supports the client applications (RPs) in two different use cases:

OData API needs to know the identity of the Client Application in order to authorize the OData properties that a specific client app can query.

Client app should use Client Credentials Flow to retrieve access_token from this authenticate service and then use access_token to access OData API.
This use case scenario follows the OAuth2 standard, access_token is a JWT and it contains the client_Id and client_class claims.

Besides the identity of client application, OData service also needs to know the identity of MLS Member who is browsing on the client application.

The authenticate service will authenticate the Member and collect the needed claims of the authenticated member.
Single Sign On (SSO) is supported until the browser session is terminated.
Client app can use Authorization Code Flow, Implicit Flow, or Hybrid Flow to get both id_token and access_token, both tokens are JWT and RP should validate them.
id_token is useful when member logout; access_token will contains claims of authenticated member and client app.
Client app should follow OAuth2 standard, attach the access_token as a Bearer scheme parameter in Authorization header of http request send to OData API.

Client Application Registration

All client apps need to be registered before working with OData OP. In some cases, one client app can have mutiple use case scenarios and need to be registered as separate client apps and each registered client app has its unique client_Id. Each registered client app follows only one type of authorization flow.

Single Sign ON

After a member login, the OpenID Connect authentication service will not prompt user to login again in the same browser session. The claims of current authenticated member will be applied until the end of browser session. The browser session continue as long as there is one browser window remained open (even it is minimized). The Browser session is terminated when all browser windows are closed.

No support for Single Sign Off. When a member has worked on more than one client app (In different domain) on the same browser session (by working on more than one browser windows simultaneously), his logout on one client application does not affect his continue operation on another already logged in client application; But the login page will be prompted whenever authorize request is submitted.

External Authentication Providers are not enabled.

Because in our use cases scenarios, some needed memebr attributes will not be provided by external authentication provider, so we does not enable any external authentication providers such as Google, Facebook...

NB: Due to transition to IdentityServer4 from IdentityServer3, additional updates to the current documentation are still pending, but functionality for client applications should not be effected.

Scopes

Besides the claims regarding the client app already presented in access_token, the claims regarding to authenticated user (Member) can also be requested from OP. These claims are grouped into scopes. The OP defined a set of scopes as well as claims that can be found in the metadata of the OP. Each claim can be in one of the two scope types:

  • Resource (aka API Resource) is for the claims will be collected in the access_token. Each Resource type of scope is for a specific OAuth2 protected resource endpoint (e.g. OData API Service); the resource scope specifies the requested claims of the authenticated member and these claims will be needed by the specific resource endpoint when processing the request send from RP.
  • Identity (aka Identity Resource) contains the claims to be collected in id_token or can be retrieved from UserInfo endpoint. Each claims contained in Scope is represented by the type ScopeClaim. Beside the claim type, the ScopeClaim contains a flag named "AlwaysIncludedInIdToken". If this flag is set to true, the claim value is cached when user is authenticated and the claim is collected in the id_token when TokenResponse is requested by RP. If this flag is set to false, the claim value will need to be requested separately by RP from UserInfo endpoint after RP getting the TokenResponse. UserInfo endpoint is a protected OAuth2 resource endpoint that needs access_token to access. RP can request the claim of current authenticated user from UserInfo endpoint and typically put the claim value in cookie for application to use.