Authorization server and Open ID Connect provider plug-ins

The nevisAuth OAuth2 authorization server and Open ID Connect provider plug-ins basically implement the two roles authorization server and resource server as defined by the OAuth 2 specification in the AuthorizationServer and the AccessTokenConsumer. The AuthorizationServer issues access tokens to third-party clients with the approval of the resource owner. The AccessTokenConsumer accepts access tokens issued by the AuthorizationServer and grants access to protected resources if the access token could be successfully verified.

The designated usage of the AuthorizationServer and AccessTokenConsumer are illustrated in the following figure:

The previous figure depicts an authorization code flow as it takes place in a typical Nevis environment consisting of nevisProxy and nevisAuth:

1. An end user requests a page from a third-party web application.
2. As the web application requires access to the OAuth2 protected resource to fulfill the request in this scenario, the web application redirects the end user to Nevis with an authorization request.
3. nevisProxy intercepts the request and sends it to nevisAuth via the internal SOAP interface, where it is validated by the AuthorizationServer AuthState (hereby implementing the authorization endpoint). After authenticating the end user and establishing the user's consent (interaction not shown in this figure), an authorization response including an authorization code is sent to the web application via an HTTP redirection.
4. After receiving the authorization code, the web application sends a token request including the authorization code to Nevis.
5. nevisProxy intercepts the request and sends it to nevisAuth via the internal SOAP interface, where it is validated by the AuthorizationServer AuthState (hereby implementing the token endpoint). After successfully verifying the authorization code, a token response including an access token and if requested an ID token and refresh token are issued directly to the web application.
6. Now being in possession of an access token, the web application requests the OAuth2 protected resource. This request is intercepted by nevisProxy and sent for authentication to nevisAuth, which verifies the submitted access token.
7. After successfully verifying the access token, the resource request is passed to the resource, which then responds to the web application.

n the designated usage scenario, multiple sessions are established in the process of the authorization code flow. In step 3, a session with the end user's browser is established as the end user will be authenticated (user ID = end user's ID). In step 5, a session with the web application is established as the client will be authenticated (user ID = client_id). In step 7, a virtual session bound to the access token will be established with the web application (user ID = end user's ID associated with the submitted access token). I.e., whenever the web application requests a resource and supplies an access token, the session previously established when sending the same access token will be selected.

info

The most productive setups include two or more nevisAuth instances in a load balancing or failover configuration (or a combination of both). In such a scenario, a nevisAuth instance must be able to consume authorization codes issued by any of the other instances. To enable this, a common OutOfContextDataServices (see chapter Shared out-of-context data) must be used. Note that all instances must use the same key to sign token responses for this scenario to work.