New to okta here. I am trying to establish an OAuth2.0 flow.
I would like to bypass the okta-hosted sign-in widget and handle authorization through my backend nodejs service.
Brief design:
User → My frontend → creds → backend service → authenticate and respond back with access token / JWT (Skip redirection to Okta sign-in widget)
Now, I am able to retrieve a session token with username and password via the authenticate API.
I’d like to generate an access token based on this session token. When I try to call the /authorize endpoint I am getting a Clients with 'application_type' of 'service' are not allowed to access the 'authorize' endpoint error. I am not looking for a service token (client credentials) but an actual way to generate an access token for the user on my backend service.
You are going to be very limited in terms of what you can do this way. Please take a look at my (short) or (slightly longer) videos about why you should not skip redirecting to Okta for your users logging in!
If you really want to exchange passwords for tokens directly, then you can use the Password grant for your application so that there is no interaction with the authorization endpoint.
Yes, you’ll need to enable the password grant type for that application in the application’s config, as well as make sure you have a policy configured that allows the password grant type to be used.
From your earlier comment: You are going to be very limited in terms of what you can do this way.
I assume you mean I might not be able to utilize certain features like for e.g. social idp.
This is fine at the moment.
I’m trying to understand if there are any vulnerabilities in this flow.
User inputs creds on my sign in page → backend service has the client id/secret (might create a JWKS key pair later) → backend embeds user creds in the request to okta and gets an access token.
Okta is invisible to the users. Okta is where we store basic user info.
When your application is handling the user’s password, you’re entirely responsible for the security of the flow. The nice thing about sending the user away over to Okta is then your application never sees passwords and you don’t have to worry about accidentally doing something wrong when handling passwords.
Social IdP integration is one limit. Another is multifactor authentication. You won’t be able to add multifactor auth when using the password grant.
There is no way to add MFA to the grant_type=password flow.
The best bet is to redirect the user to Okta using the authorization code flow. That means Okta is hosting the sign-in widget so you don’t need to worry about integrating that with your app at all. What your app sees is just a couple of HTTP requests.
@aaronpk I understand your point. However we have legacy user auth modules because of which that may not be possible.
If I get a session token from Authentication | Okta Developer
Can this token be exchanged for an access token using the /authorize endpoint on oauth/default?
We have a live existing application (with both mobile & web frontends) that has a custom login page. We’ve been handling our own authentication/authorization on the backend. We’ve got a huge user base on the app.
If we decide to use Okta’s sign in widget, we don’t have a way to check whether the incoming user exists in our database. As a result, the user would be treated as a new user with the okta flow.
We need an API (hosted on our infra) that can do some checks on our side and then grant the access token.
I understand the grant_type=password does not support MFA.
I’d like to explore all other options which allows me to handle this on our backend service.
