Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.okta.com/docs/guides/implement-grant-type/authcode/main/ below:

Implement authorization by grant type

Before you can implement authorization, you need to register your app in Okta by creating an app integration from the Admin Console.

The following sections outline the main requests required to implement the Authorization Code flow using direct calls to the OIDC & OAuth 2.0 API (opens new window). Typically, you don't need to make direct calls if you're using one of the Okta SDKs.

To get an authorization code, your app redirects the user to your authorization server's /authorize endpoint. If you're using the org authorization server, then your request URL would look something like this:

Note the parameters that are being passed:

• client_id: The client ID of the app integration that you created earlier. Find it in the Admin Console on your app integration's General tab.
• response_type: The value is code, which indicates that you're using the Authorization Code grant type.
• scope: The value is openid, which means that the /token endpoint returns an ID token. For custom scopes, see the Create Scopes section of the Create an authorization server guide.
• redirect_uri: The callback location where the user agent is directed to along with the code. This URI must match one of the Sign-in redirect URIs that you specified when you created your app integration earlier.
• state: 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 (opens new window) for more information on these parameters.

If the user doesn't have an existing session, this request opens the Okta sign-in page. If they have an existing session, or after they authenticate, they arrive at the specified redirect_uri along with a code. For example:

This code remains valid for 300 seconds, during which it can be exchanged for tokens.

To exchange this code for access and ID tokens, you pass it to your authorization server's /token endpoint. If you’re using the org authorization server, then your request would look something like this:

Important: The call to the /token endpoint requires authentication. In this case, it's Basic Authentication with the client ID and secret Base64-encoded. You can find the client ID and secret on your app integration's General tab. This requirement is why this call is only appropriate for applications that can guarantee the confidentiality of the client secret. See Client Authentication Methods (opens new window).

Note the parameters that are being passed:

• grant_type is authorization_code, indicating that you’re using the Authorization Code grant type.
• redirect_uri is the URI that was used to get the authorization code.
• code is the authorization code that you got from the /authorize endpoint.

See the OAuth 2.0 API reference (opens new window) for more information on these parameters.

If the code is still valid, your application receives back access and ID tokens:

When your application passes a request with an access_token, the resource server needs to validate it. See Validate access tokens.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4