Implement Delegated Access with OpenID Connect Authentication for Okta Single Sign on – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Implement Delegated Access with OpenID Connect Authentication for Okta Single Sign on – InApps in today’s post !
Read more about Implement Delegated Access with OpenID Connect Authentication for Okta Single Sign on – InApps at Wikipedia
Gravitational sponsored this post.
Can you imagine having to give Spotify your Facebook login information for just an email address?!
Virag joined Gravitational in January of 2020, after co-founding a software code auditing company for Ethereum applications. Having joined Gravitational, Virag continues to learn about trending technologies and produces high quality written and video content. In his free time, Virag enjoys rock climbing, video games and walking his dog.
Of course not. There has to be a better way. The concept we are looking for here is Delegated Access. How can we delegate some degree of access to a third party entity without having to provide login credentials? That’s what OAuth does. But one thing the protocol does not do is communicate identifiable information about who is requesting privileges. There is a profound difference between granting Spotify access to your Facebook account data and letting Spotify make a post as you. By introducing an ID token, OpenID Connect Authentication (OIDC) adds an authentication feature to OAuth’s powerful authorization utility.
By running through a sample OIDC implementation to support Okta Single Sign On (SSO) for Teleport, we will see how the introduction of one additional token does what OAuth could not.
Case Study: Okta SSO for Teleport
OAuth uses different Grants and Flow to determine the sequence of events. We will look at the most common type, the Authorization Code Grant, and go through step by step.
Teleport prompts the user to log in via their organization’s SSO provider. In this case, let us use Okta as our IDP.
The Teleport user clicks “Log In” and is redirected to Okta’s authorization API endpoint with the following parameters included in the HTTPS request:
What do these parameters mean?
authorization_serveris the URL that Okta is exposed to. All IDPs will provide a URL to redirect to, usually an API. For Okta, this is
response_type=codewill let the Okta know that Teleport expects an authorization code.
client_idprovides a string to Okta, which can check against a registry of authorized clients. IDPs like Okta will require clients to be registered to help identify them. Let’s use
12345as Teleport’s registered ID.
redirect_uriinforms Okta which pre-configured URL to direct the Teleport user back to, with all the variables that Teleport needs. For this example, we can take the sample redirect URL provided in the Gravitational documentation as
scopedefines the limitations in accessing resources. For OAuth, these scopes are internally defined by the resource application. But recall that OIDC was created to standardize the way to get rudimentary identity information. At minimum, we must use the standard claim
openidand perhaps an additional standard claim,
stateis a string randomly generated by Teleport and passed back and forth with the Okta. By passing this string, both Teleport and Okta know they are speaking to the same device between communications. For this example, let’s say the state string is
syl(my dog’s name).
Putting together all these parameters, the URI a Teleport user is directed to after accepting the login prompt will look like:
Once Okta receives the query, it will verify the
client_id against an internal registry for the Teleport application. Knowing Teleport is expecting an authorization code, Okta will send the user back to the redirect URL with the code and the state parameter that was passed. Our next stop is:
After receiving the code, Teleport will automatically query the Okta token endpoint to exchange the code for a token with the
client_id parameters included. Two additional parameters are present:
grant_type=authorization_codeinforms Okta the flow is
client_secretcomes from Okta during the client registration process. This string should be secret and not publicly accessible. Because Teleport is hosted on our own infrastructure, which we know to be safe, we feel comfortable passing this parameter. Otherwise, we would use the PKCE extension and hash a generated string. In this case, our secret is
This exchange happens through a post request that will look something like:
code, Okta is able to verify the Teleport client’s request and issues a JSON payload encoded with the bearer token, an expiry time, and perhaps a refresh token. A successful response may look like:
id_token is issued as a JWT and must be decoded. Given our chosen scopes of
Now that we have obtained the access token, all that is left is to make an API request on behalf of the Teleport user and receive the resources desired. We do this by passing the access token as a Bearer credential in the HTTPS authorization header.
There is a simple beauty to how OIDC works on top of OAuth, given the scale of the problem it solves. However, developers must be extremely careful when designing applications that are compatible with OIDC, as it deals with sensitive and private user information.
Feature image via Pixabay.
At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.