The following sequence diagram illustrates the Authorization Code Grant Flow:
Please find below a simplified explanation of how this authentication process works in the Authorization Code Grant flow:
The Authorization Code Grant flow redirects the user to a login page hosted by Auth0. Here, the user completes the authentication process, and upon successful authentication, receives an Authorization code as query parameters in the callback URL.
Subsequently, this Authorization code is included in the request to the token URL, along with the Consumer ID and Consumer Secret, to obtain the access token and refresh token.
The obtained access token is then used to authenticate SCIM APIs’ access.
The OIN submission form requires specific parameters, including Consumer ID, Consumer Secret, Token URL, and Authorization URL. However, due to the nature of the Authorization Code Grant flow, we anticipate needing to provide the credentials for the login step explicitly.
It’s worth noting that the submission form does not provide options for entering a username or password, which has led to our inquiry.
Can you please provide clarifications to the following questions:
Since the Authorization Code Grant flow step requires a login step, and the username and password needed to log in are not part of the submission form, please clarify what username and password Okta uses internally to authenticate this step.
Given that Okta doesn’t support refresh tokens, how does the Okta->SCIM API integration refresh its credentials to keep making calls? Will Okta log in each time the access token expires, to fetch a new token?
Since we are using Auth0 as the Authentication server, the query parameters passed while making a call to the ‘/authorize’ endpoint influence the subsequent handling of the request. Therefore, could you please provide documentation on how Okta calls the authorization endpoint?
When the admin adds your application to their org, they will need to set up the provisioning portion themselves, which will involve Okta opening a browser pop-up where we will make the /authorize call to the authorization server specified for your app. So the admin configuring the application in your customer’s tenants will be the one that provides the username and password to complete the authentication.
Refresh tokens, while not supported when using the SCIM Test apps listed in the app catalog, will be retrieved, stored, and used once your application is added to the OIN. I’m looking to get this added to the guide you mentioned.
Do you have any specific concerns about the parameters requested by Okta? For example, does your SCIM integration require that certain scopes be requested?
@andrea Thanks for the quick response. Based on the information you provided, we have some follow-up questions. It would be greatly appreciated if you can provide additional help in regards to this.
When the admin adds your application to their org, they will need to set up the provisioning portion themselves, which will involve Okta opening a browser pop-up where we will make the /authorize call to the authorization server specified for your app.
Is it possible to include additional parameters in the authorization endpoint in the submission form, beyond those automatically added by Okta? If such customization is allowed, could you provide details on the parameters Okta will add by default and specify what additional parameters we have the flexibility to include in the endpoint URL?
We are using Auth0 as the authorization server and the Auth0 application we have set up supports the following parameters:
a. client_id - The Auth0 application’s client ID.
b. response_type - This must be set to code since we are using the OAuth Authorization Code Flow.
c. redirect_uri - This is the URI to which the user will be redirected to after the authentication flow is complete. Based on our understanding, this URI depends on the appName provided by Okta after the integration is submitted to the Okta Integration Network (OIN) and the initial review is completed. Reference from Okta documentation. Can you confirm whether this is the callback URL that will be requested after the admin enters the credentials in the browser pop-up?
d. scope - What are the default values that Okta passes within the scope? It is important to note here that offline_access must be included if refresh tokens are to be generated. Does Okta include this within the scope?
e. audience - The target API (in this case, the SCIM API) we want to grant access to. Does Okta pass the SCIM Base URL as the audience parameter? If not, can we include the audience parameter while specifying the authorization endpoint in the submission form?
f. state - Does Okta generate this state parameter automatically and pass the value along?
g. connection - (Optional) The connection configured to our application.
So the admin configuring the application in your customer’s tenants will be the one that provides the username and password to complete the authentication.
How does Okta know these credentials, as the submission form didn’t ask for the credentials that will be used to authorize?
Refresh tokens, while not supported when using the SCIM Test apps listed in the app catalog, will be retrieved, stored, and used once your application is added to the OIN. I’m looking to get this added to the guide you mentioned.
We’d like to seek clarification regarding the use of refresh tokens, as mentioned above. Specifically, how will the refresh tokens be utilized for token refresh, and what parameters will be included in the request body for refreshing tokens?
As per the OAuth 2.0 Standard, the request method should be POST and the content-type should be x-www-form-url-encoded, and the request body parameters should be all of:
a. client_id, client_secret, grant_type, code, and redirect_uri for the access token API call, where grant_type = authorization_code, OR
b. client_id, client_secret, grant_type, and refresh_token for the subsequent API calls to generate/refresh a new set of access tokens, where grant_type = refresh_token. Can you confirm if Okta follows the same standard and passes the above mentioned parameters in the request body of the token endpoint?
Do you have any specific concerns about the parameters requested by Okta? For example, does your SCIM integration require that certain scopes be requested?
For now, our integration requires the scope to be set as openid profile email offline_access. Can you confirm if Okta passes all these values within the scope? If not, can we include it in the authorization endpoint while submitting the form?
I’ve seen customers/partners able to pass additional authorize parameters along as part of the authorization endpoint, which you could try with the audience and connection scopes (I’ve seen this mostly regarding custom scopes). I’m not as sure if this is something that would be accepted during the OIN submissions process (I mostly help with custom apps), but you can definitely check with our OIN team when making your submission.
And you should see that offline_access cope and a state parameter are included in the request coming from Okta
Okta would not know these credentials ourselves. The admin of our mutual customer is the one that will need to authorize the connection when setting up the integration in their Okta org. During the submission process, I believe the OIN team will ask for credentials they can use through the duration of their tests.
And yes, as far as I know, Okta will meet your expectations for the /token request. If you do see an issue though, definitely let us know what errors you are seeing.
