Hi, I’m creating an OIDC app integration using Authorization Code Flow with my web app, which I intend to publish to the OIN. On my Okta Application settings, I have set “Login initiated by Either Okta or App.” I have selected Grant Type: Authorization Code Flow.
When I try to save these settings, I get an error: ‘Okta can only initiate the login for Web and SPA apps with the “implicit” grant type.’
I can only solve this issue by also selecting “Implicit/Hybrid Flow” as another Grant type. However, I’m concerned about this preventing my app to be accepted into the OIN, since if I understand correctly, a nonce is a required ID Token parameter if the app is using Implicit Flow. A nonce is not something my application currently includes.
Why can’t we just enable Authorization Flow in this case? My application is still going to go through the full Authorization Flow, but we are just allowing the user to initiate this login from the Okta side. Alternatively, if Implicit Grant must also be selected, do you think it will cause any issues when I submit my app for approval for OIN, if it doesn’t include a nonce? Thank you!
Hello,
Yes even if are setting up Okta ‘OIDC Compliant’ IdP initiated, the application still requires implicit to be selected. This makes sense if you choose to do ‘Okta Simplified’, but I am not sure why it is required for ‘OIDC Compliant’.
I recommend bringing this to the attention of the engineer you work with when the application is submitted to the OIN. I don’t believe this will cause the application to fail submission, but I don’t know for sure.
Hi @fszeto are you enabling the ‘Login initiated by Either Okta or App’ as you want a button to show up in the dashboard? What’s the end goal you’re aiming for? Yeah, Implicit isn’t something you want to use.
Hi @abole, yep that’s correct - I want a button to show up in the dashboard and allow users to click to initiate login to my app. I don’t want to use Implicit Flow but the UI for my integration won’t allow me to save my settings if I select ‘Login initiated by Either Okta or App’ without also selecting Implicit. Is there something I am missing about these settings? Thanks.
Thats a known limitation at this time and a previous feature request to support this has not been accepted to have this enhancement added to our backlog (filed here). If you do not want to enable Implicit flow, you can always make a Bookmark app that users can use to get redirected to the OIDC app.
Thanks @andrea, I’m alright with enabling both Authorization and Implicit Flow on my Okta App Integration, since my app will enforce strictly Authorization Flow anyway. My only concern was the integration passing approval for the OIN. It sounds like it shouldn’t be an issue though.
You haven’t missed anything in the settings @fszeto. To initiate Auth code with Proof Key for Code Exchange (PKCE) your app needs to generate a code challenge and verifier which are required for the /authorize and /token calls. Okta can’t (shouldn’t?) generate this on behalf of your app - hence no IdP initiated SSO.
One way to create the experience you’re looking for is to create a separate Okta bookmark app pointing to a new page on your app which auto initiates the auth code dance.
In your discussions with the OIN team ask them about this - I’d be curious to understand what the official position is. They may have another suggestion.
Got it, thanks @abole. Since I am not implementing PKCE, just web app Authorization Flow, I believe I won’t need to generate a code challenge and verifier. I’ll ask the OIN team for their suggestion as well.
PKCE is expected by default these days for a SPA - it’s the future. Note the unselectable radio button in the screenshot. See how you go with the OIN team.
Also most security teams at larger organisations wanting to use your app (depending on your target market) would expect your app to use it. You may get extra security scrutiny if you’re not following best practices and providing good security defaults. My view is somewhat biased as I predominantly work in financial services security
@abole Is this still true for SPAs that interface with a secure backend server? Sorry for the confusion - my implementation does include a secure application server that is able to safely store a Client Secret and is what will be making authentication requests to Okta.
