During the 'Request an authorization code' step, is it possible to pass user credentials in request?

Questions
1

I’m implementing the Authorization Code flow w/PKCE, so I have no client secret, and I’m trying to fetch a auth code from the Okta servers to then subsequently hit the token endpoint to fetch a valid bearer token which I’ll then use to send to a verifier that lives in an AWS lambda, but can’t seem to find a way to get the code programmatically? Is this not possible? All of the OAuth docs seem to state that this is possible, but the redirects stop at the login page with Okta, so if my account is set to the “browser” type is there no workaround for this to fetch a test token with credentials?

2

If you’re implementing the authorization code flow, that’s explicitly for use with a user interacting with a browser. If you want to get an access token without user interaction, you would use the client credentials flow.

1 Like
3

So, level-set, here’s the information I have and am trying to work through:

Flow to be implemented: Auth flow w/PKCE

  • I have the client id, issuer, and audiences
  • It’s for use in an SPA w/OIDC
  • The grant type is “Authorization Code”
  • The response type is “code”
  • I have a redirect URL configured for the SPA
  • The consent method is set to “Trusted”
  • Users are validate through an AD group

Unknowns currently:

  • Trying to figure out what Okta libraries are used to pull credentials IWA (kerbrose token) down and verify the user against the AD group.
  • Is it possible to automate the above set to test the JWT verifier that sits in the cloud? B/c the SPA page will load up, the “okta lib will pull down the IWA down and verify”, then the SPA (some form of js) will generate a bearer token that will be sent in the “Authorization” header to the AWS lambda who will check the JWT

See what I’m trying to do?

4

Is your Okta org configured to have users authenticate via AD? If so, your SPA won’t ever see that happening, which is good.

You really don’t want to think of this as the SPA “generating” a bearer token or pulling down credentials. What’s actually happening is the SPA sends the user out to Okta, and Okta authenticates the user via AD and your SPA is able to get the bearer token from Okta using the authorization code and PKCE.

5

Yeah, the Okta admin configuration is the part I don’t see as it’s at the enterprise level of course. I just have the pieces to the puzzle I need to put it all together.

So, in the SPA, I’m using the “@okta/okta-angular” provided library to handle the authorization part, but all I really need to know how to do now is how to extract the bearer token out from the authorized session and send it along in all subsequent requests.

I’ve been trying to find a workaround that doesn’t require front end code changes, but looks like I don’t really have a choice here.

Any way you can point me to the proper docs or function in that angular okta lib. where one my expect to pull out the bearer token from a logged in user within this flow context?

6

There should be a getAccessToken method on the angular client:

1 Like
7

So, my problem remains:

Because the redirect URL configured on the actual okta admin panel is the “production” URL for the application, when I run the front-end code locally, by the time I can pull out the access token to grab it for testing, the redirect has taken me out of context and I can’t stop it.

Is there any function that okta provides that you are aware of in the “@okta/okta-angular” library that allows you to intercept the redirect event and somehow prevent it while at the same time not dropping the request?

8

Are you saying that you’re trying to use production credentials to run a test app locally? That isn’t going to work well. You should get the Okta admin to add either a separate entry for your development application or add your localhost redirect URL as one of the allowed redirect URLs for the application.

1 Like
9

Ok, yeah unfortunately that’s what I’m saying lol. The DEV environment version of the url anyway, but yeah ok that’s about what I expected you to say. Just thought maybe I was missing an alternative workaround.

Thanks for responding so quickly.

1 Like
10

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.