Overview
Open Authorization (OAuth) is a standard for token-based authorization for applications. Frequently, it has also been used to provide authentication for many applications, and thus OpenID was created to amend the OAuth paradigm to officially supply authentication services.
OAuth / OpenID relies on the idea of a trusted authorizing entity to act as a middleman between a client (software or device) and some resource (name, email, employee #, etc.). A resource is a piece of secured information to which a user can grant access.
This standard provides multiple grants, also known as flows, in which a client can request a resource or authenticate a user to a system. While there are others, there are four main grants (flows):
Authorization Grant
When a client would like to authenticate a user, the client would be redirected to the authorizing server’s login page as it is trusted. The user would attempt to log in and if successful, the server returns an authorization code. The client would then exchange this code for an authentication token along with the requested resources. Before the authorizing server replies with the token ad resources, the authorizing server validates the client via a shared secret key, also known as the client’s secret.
An important note here is that as part of the user’s login process, they must give consent for the client to receive the requested resources.
A more detailed explanation can be read here:
https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
Implicit Grant
An implicit grant is very similar to Authorization Grant except that it removes the step of exchanging the authorization code or the authentication token. A client would redirect the user to the authorizing server’s login page, the server validates the client along with the client secret. If the client is valid, the user will log in. If login is successful, the authorizing server would return the access token and resources.
Again, An important note here is that as part of the user’s login process, they must give consent for the client to receive the requested resources.
A more detailed explanation can be read here:
https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type
Resource Owner
This is the least secure of the authorization grants. Essentially, the client would pass the user’s credentials and (possibly) the client’s secret to the authorization server. Generally, the secret is only transmitted when the client is an internal process, not a public service. The authorization service would authenticate the user and return the access token, sometimes a refresh token, and finally the requested resources. This is primarily used when the applications requesting information are highly trusted and have a secure connection.
More information can be read here:
https://oauthlib.readthedocs.io/en/latest/oauth2/grants/password.html
Client Credentials
This grant type is not about authenticating users, it’s about authenticating a client (software). This would most likely be used internally when an application would like to access an API or some other sort of secured resource or service.
More information here:
https://auth0.com/docs/flows/concepts/client-credentials
PSAccess / Titan
Several months ago, the team at Western had identified a need for its enterprise framework, Axiom, to have the ability to modularize components of the Titan Server. During our internal assessment of Axiom’s services, we identified that we need to allow Axiom to run its services on separate servers. These services include logging, caching, security, load balancing, etc.
Due to the nature of security, we identified OAuth2 / OpenID as the mechanism of choice as it gives the most flexibility and is a proven standard. Other options included a custom protocol or SAML. To minimize risk and enhance security we chose not to do a completely custom protocol and we also felt that SAML was a little dated – both were ruled out. OAuth has a similar feel to SAML but is much more current.
The great thing to this approach is that it would also allow 3rd party entities to authenticate against our servers. This ability is well suited for PSAccess as it does not need any other RHA interoperability or integration – just employee authentication.
Our implementation of OAuth relies on the leading OAuth provider for C# – IdentityServer (https://identityserver.io/). While IdentityServer does do 90% of the heavy lifting in terms of handling the grant flows, we have implemented its provided interfaces to work within our security infrastructure and our client configurations i.e. Behavior can be customized based on the client / application.
Our identification service hit an internal server that will process a user’s authentication request by validating against an RHA’s active directory (via LDAP). If successful, the user will consent to providing the client with the requested resources of Name, Email, Employee Number, and employee identifier.
Since PSAccess does not part of the RHA network and is PHP/JavaScript based, it will use the Implicit Grant type where the access token and resources are returned. PSAccess will use this information to complete log in of the employee to its own system – no further interaction with RHA required.
Each RHA has its own PSAccess tenant with its own URL and is therefore considered another client. Each RHA could technically have their own grant flow and / or custom resources provided to PSAccess. However, more importantly, this could provide other 3rd party applications the ability to log in against RHA Active Directories without ever having to be part of the RHA network.
Below is a sequence diagram of how PSAccess would authenticate against the Active Directories:
To note, the sequence diagram does not differentiate the WWW and our internal network. At a high level, the following diagram can depict this segregation.
Sample Screen Cast
While viewing the screen cast, notice the URL in the browser changing to a different service and then back again once authenticated.
