Does grant_type=authorization_code always require a manual intervention for providing username/password

api

#1

Hi Team,

I am trying to use the grant_type=authorization_code but when i read it from the URL(https://developer.okta.com/authentication-guide/implementing-authentication/auth-code), it is saying
"If the user does not have an existing session, this will open the Okta Sign-in Page".
So i am interested in to get the token with grant_type=authorization_code without any manual intervention as we have some client which have automated script in place to call the APIs.

So, Is there any way to get token without any manual intervention?
Please help…

Thanks
Manjit Kumar


#2

Hi Manjit,

If you are working on B2C scenarios and do not need to show the Okta Sign-In Page for the end-users, there are multiple ways of doing it and following are some of the options
Option:1

  1. Build a custom sign-in page.
  2. Use Authn API with username & password to get the session token.
  3. Pass the sessionToken as one of the query parameters you will be able to get the tokens.
    Option: 2
    Build ROPC (Resource Owner Password flow) - Not recommended.

#3

Hi Anand,

So you are saying to create a custom sing-in page but how can we provide the credentials to that custom page.For that we need Manual Intervention.
Actually i want no manual intervention, means i want to get the token through some API call.
Is it possible to do with grant_type as authorization_code.

I am able to get the token without any manual intervention with grant_type=password using API of Okta.

Thanks,
Best Regards,
Manjit Kumar


#4

If you are trying to write scripts for testing the authorization code flow, @Anand first option is what you more than likely want to do.

You can use the Authentication API or okta-auth-js to get you an sessionToken and use the sessionToken in the authorize call to get an authorization code.

https://developer.okta.com/docs/api/resources/oidc#authorize


#5

Hi @mksmanjit,

Not sure, What do you mean by manual intervention? If you are planning to get the user based tokens then the sessionToken is one way and if you are thinking of protecting the API’s or system-system integration, then I would recommend going for OAuth Service.


#6

Hi @Anand,
I was thinking of protecting my API’s and for that i have to use OAuth service.
So i created the OAuth2.0 application on Okta and by using the grant_type=password, i am able to get the token by calling the APIs, but i was going through the grant_type=authorization_code, For that i wanted to check whether i will get the token directly by calling the APIs(without any manual step).
Is it possible with grant_type=authorization_code?

Thanks,
Best Regards,
Manjit Kumar


#7

The type of application you are building dictates which flow you need to use:
https://developer.okta.com/authentication-guide/auth-overview/#choosing-an-oauth-20-flow

I think for us to understand how to help you, you need to bubble it up to a higher level and tell us what you are building.


#8

Hi @tom

We have a REST APIs which other product is consuming or sometimes we are calling our REST APIs from the REST Client or the SOAP UI.
We are using OAUTH2.0 in our product and if somebody want to access our APIs, they have to first gather the token by calling the /token API and in subsequent API calls they have to provide the token in the header and if the token is valid then we will process their request.

Now we are adding support for SAML in our product, So all the user credentials are now moved to the IDP server. We successfully did the Change for the UI part but for Non-UI(REST APIs or Command Line) we are doing some research means what is the best approach to authenticate the APIs as credentials are now on IDP server.

So for the APIs part, I added Authorization server on the Okta and we are using Okta API https://dev-451813.oktapreview.com/oauth2/default/v1/token and passing grant_type=password to get the JWT Token.
Once we get the response code 200 and JWT Token(means the user is valid) we are extracting the username from it and will pass it to our application, then our application will create its own Token and will return to our APIs caller and we will discard the JWT token after extracting the user name as we don’t want any other information from IDP server.

First i want to check, Is this the correct approach?
If yes then I am checking if the similar work flow will also work with the grant_type=authorization_code.
Actually i don’t want any popup or re-direction happen on the APIs side and it ask for the IDP server credentials as i don’t want manual intervention, I am looking for APIs where i will provide all the needed information including username and password after that i will get the JWT Token.
I am able to do this the grant_type=password but i also wanted to check whether the same possible with the grant_type=authorization_code.

Thanks,
Manjit Kumar


#9

Hey @mksmanjit,

I’m going to piggy-back on some of the responses here - as I think the correct approach has already been discussed. But let me try and reiterate a few things.

Since you’re looking for no “manual intervention”, you have two possible solutions:

Use the resource owner password flow
Based on how much control you have over your app - this might be the best option for you. Here, you’ll need to embed your clientId and clientSecret into your application to make calls to the /token endpoint as you mentioned before. This flow isn’t recommeneded for Single-Page Apps, or anything considered a public client (see client types in the OAuth 2.0 spec).

Use the sessionToken flow
As mentioned earlier, you can leverage the Okta sessionToken to bootstrap your login flow. Essentially:

  1. Submit user credentials to /api/v1/authn to receive a sessionToken
  2. Perform the /authorize call using the sessionToken and setting the reponse_type=code
  3. Once the code is returned, exchange it for an accessToken via the /token endpoint

Both flows only require the user credentials - and do not require using a browser and/or any “manual intervention”.

Hope this helps!


#10

Thanks @jmelberg
One thing i want to understand that everybody is saying OAUTH2.0 is an authorization protocol not Authentication protocol but i am using it to authenticating my APIs.

Is am i doing in a right way?

Thanks,
Manjit Kumar


#11

To add on to what @jmelberg said: the authorization code flow (response_type=code) is specifically for web flows. In other words, it is expected that the user will be using a browser and interacting with a UI. If you are dealing with a service application that will not display a UI, or does not interact with the user via a browser, then the resource owner password or client credentials flows are what you are looking for.

One thing i want to understand that everybody is saying OAUTH2.0 is an authorization protocol not Authentication protocol but i am using it to authenticating my APIs.

This is a good question. It’s something that is frequently misunderstood. OAuth 2.0 is built for authorization, although many people use it for authentication. Using OAuth 2.0 for authentication works but isn’t recommended. OpenID Connect (an extension on top of OAuth 2.0) is specifically intended for authentication. Watch this video for a deeper explanation :slight_smile: https://www.youtube.com/watch?v=996OiexHze0


#12

Thanks @nate.barbettini. It is really a good video.This video has all my answers.