Without using existing libraries, you can make a direct request to Okta's OIDC & OAuth 2.0 API through the
Request for tokens
Using this flow is very similar to the authorization code flow
except that the
id_token instead of
Your application redirects the user's browser to your Authorization Server's
/authorize endpoint. If you are using the default Custom Authorization Server, then your request URL would look something like this:
Note the parameters that are being passed:
client_id matches the Client ID of your Okta OAuth application that you created in the Set up your app section. You can find it at the bottom of your application's General tab.
token. It could also be
id_token or both.
openid, which is required, but additional scopes can be requested. See the Create Scopes section of the Create an Authorization Server guide.
redirect_uri is the callback location where the user agent is directed to along with the
access_token. This must match one of the Sign-in redirect URIs that you specified when you created your Okta app integration in the Set up your app section.
state is an arbitrary alphanumeric string that the Authorization Server reproduces when redirecting the user agent back to the client. This is used to help prevent cross-site request forgery.
See the OAuth 2.0 API reference for more information on these parameters.
If the user doesn't have an existing session, the request opens the Okta sign-in page. If they have an existing session, or after they authenticate, the user is redirected back to the specified
redirect_uri along with a
token as a hash fragment:
Your application must now extract the token(s) from the URI and store them.
Validate access token
When your application passes a request with an access token, the resource server needs to validate it. See Validate access tokens.