I have an Rails app using Devise, and I need to setup OKTA as an SSO/omniauth provider (using dandrew’s Okta Oauth2 gem). In an effort to figure this out, I created a dev account and created an application.
Using the dev account, I’ve got SSO working with the default authorization server, but the real-world application I need to interface with uses the Org Authorization Server (no auth server id in the base url). Unfortunately, my efforts to use the org authentication server has hit a roadblock - specifically, the callback returns an invalid_credentials error.
My searches for this vague error has returned equally vague results, it doesn’t seem to be a well-documented error response.
The dev console system log shows nothing but successes:
Is the invalid_credentials error returned by Okta or by OmniAuth? If it’s returned by Okta, can you please provide the X-Okta-Request-Id response header value?
The X-Okta-Request-Id shows a successful authorization code exchange with no errors on your developer tenant. I’ve checked the invalid_credentials error for it and the only error found was on /api/v1/authn at March 4:18:47 UTC and it occurred due to invalid username or password. You can check this event also in your Okta org’s System Logs by searching for Xmm4J6P1okXzdnl3s9hCHgAAAag.
Is there any other error registered when using the org authorization server?
@nik In my case it turned out to be a bug in v0.1.0 of the omniauth-okta gem, specifically in lib/omniauth/strategies/okta.rb. The class method uid was attempting to call the instance method raw_info, which obviously doesn’t work.
If you’re using an older version, check that out. We patched it to include uid as an instance method and call that instead. I think it’s been fixed in more recent updates.
@nik did the patch work ? I am running into a similar issue right now. And seeing that it’s working for the dev account I don’t really understand.
Thanks in advance
I did not implement the patch as recommended however while I was planning on implementing it, I noticed an authorization server mismatch issue. If you’re using the ‘default’ authorization server (which is set using ‘auth_server_id’), the same value needs to be used in the production environment. Insteading of setting it to default, I’ve actually left auth_server_id unset in production which did the trick for me.