PKCE flow - sessionToken param for Authorize endpoint

Questions
1

I’m implementing the PKCE flow for a native client application and would like to do this without prompting the user for credentials. Is it possible to call the Authorize endpoint without a sessionToken and still get back a code which can then be passed to the Token endpoint? All of my attempts to call Authorize without sessionToken do not return a code.

Thanks!

2

If you are unable to provide a sessionToken when making the authorize call, you MUST redirect to the authorize url to prompt a user to authenticate.

The sessionToken itself is proof that the user was able to complete primary authentication into Okta. Aside from including this sessionToken in the request, there is no way to complete the PKCE flow without the browser prompting the user to log into Okta. They must be logged into Okta to be granted tokens.

2 Likes
3

Just curious, why pkce if you’re not going to prompt the user for their creds?

4

I’ve been told to use PKCE as that is most secure, yet there is some desire to not have to prompt the user. Do you think that somewhat defeats the purpose of PKCE (no longer most secure if not prompting for user creds)?

5

In all the OIDC flows End User must Authenticate. PKCE are best for SPA which has protected routes. If your SPA doesn’t have secure information you need not have Okta integration.

If you want backend to Okta communication then look into this Overview | Okta Developer

6

@dschddny I believe that with auth code or auth code with PKCE the user would have to enter their credentials into the login form. To reduce the frequency of which the user is prompted you may want to look at longer session lifetimes if that’s within your organisation’s risk appetite.

I’ve seen some clunky, less secure password grant implementations where a user’s username and password are stored in a mobile app which uses them under the covers without user involvement (so the user doesn’t have to enter their credentials), but this isn’t great from a security perspective. You generally always want only the user to enter their credentials into the login experience.

1 Like