Secure interfaces - OAuth 2 and OIDC
In part 2 of our look at Identity Access and Management options for Cyber Infrastructure large facilities we will be discussing OAuth 2 and Open ID Connect, starting with an overview of how they function, and a case study of one implementation at a large CI facility.
OAuth 2
OAuth 2 is an open standard authorization framework defined in RFC 6749 which allows an authorization token to be passed from one site to another or from an authentication provider to a resource provider. It is helpful to remember that the ‘auth’ in OAuth 2 stands for ‘authorization’ and not ‘authentication’. OAuth 2 is primarily used to allow a user to authenticate with one site or entity, and pass an authorization token to another site or entity which trusts the first. To do this, it uses JSON tokens shared via various interfaces or APIs. The token does not give the bearer full authorization to the resource site, but rather enables very specific and defined access based on the request.
How it works
A typical authorization flow would look like this:
- A user clicks a login link on a website or app.
- The website/app sends an authorization code request to the authentication provider.
- The authentication provider sends a login/authorization prompt back to the user.
- The user authenticates with the authentication provider and consents to delegating authorization to share with the resource provider website or app.
- An authorization code is passed to the website/app from the authentication provider.
- The resource provider website/app returns the auth code, plus the client ID and a client secret to the authentication provider.
- The information is verified by the authentication provider and an ID and access token are issued to the resource provider.
- This token can then be used to authorize the web/app to access resources on sites via an API or other interface.
Open ID Connect
OAuth 2 functions mainly as a framework for how protocols should function to remain compatible with a common standard. Open ID Connect (OIDC) is one such protocol built on top of the OAuth 2 framework which utilizes JSON Web Tokens and API calls to allow authentication to be shared across a number of different resource providers.
While OAuth2 is concerned mainly with resource access and authorization, OIDC is designed to handle user authentication to enable single sign on(SSO) across multiple sites. Users can be sent to the Open ID portal to authenticate, then a JWT token built on OAuth 2 is issued to the requesting site to grant access.
As one StackOverflow user put it, “OpenID is for humans logging into machines, OAuth is for machines logging into machines on behalf of humans.”
How it works
A typical workflow would look like this:
- A user asked to sign into a resource provider using a single sign on provider such as CILogon.
- The resource provider sends a authorization request to CILogon.
- CILogon authenticates the user via credentials or existing authentication session and asks for consent for the new permissions to fields the resource provider is asking for (Name, email address, other stored claims).
- CILogon generates and sends a JWT access token and an optional ID Token back to the resource provider.
- The resource provider and consume and read the ID Token to retrieve the information, or use the access token to make an API request on the users behave to another site.
Working with OAuth and OIDC
There are many academic and commercial providers for OAuth 2 and OIDC. InCommon and CILogon both support these frameworks, as well as many large consumer authentication providers such as Facebook and Google. In addition, many third party commercial companies over implementation services for OAuth 2 framework interfaces, such as Auth0. For information on how one large cyber infrastructure facility was able to leverage OAuth 2 and OIDC, take a look at this paper from the CI CoE IDM Pilot group and the NEON environmental observatory.