JadeK.77895 (Customer) asked a question.
OpenID Connect - Redirect URI
I am investigating integration with OKTA for Tableau Desktop/Server -> Amazon Athena.Desktop is a weird case. Google has some recommendations for OAuth2 redirect for a installed application, which I think also would apply to OKTA.https://developers.google.com/identity/protocols/OAuth2InstalledApp Their recommendations areOption 1: Custom URI scheme (Android, iOS, UWP)Option 2: Loopback IP address (macOS, Linux, Windows desktop) For our use case Option 1 isn't enough. We need OSX and Windows support.So we need to use Options 2. However options two would use a dynamic port. So my question is what your recommendations are for the redirect URI? Can it contain wildcards for the port?Do you support installed applications?
Hi Okta team,
Is this still not possible to use wildcard for using dynamic port number as we are unable to run two instances of the application on the same machine which causes issues with listening on same port number at the same time.
Thanks,
Sudharshan.
Hi Okta,
We also need to use random port numbers with loopback (127.0.0.1) redirect URIs as specified in the draft RFC for OAuth2 native apps: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12
Is this still not supported in Okta?
Thanks,
Frank
Hi Okta, we also would like to use a wildcard for port numbers and were wondering if there is a timeline for supporting this?
Cheers,
Katrina
Emilian here again, on behalf of Customer Support.
I’ve looked-up this functionality and it appears we have had an internal request on this functionality, however there has been no traction on it.
Upon further consulting with our Developer Support team, it’s been confirmed that we do not have any plans on implementing this in the near future, as a redirection endpoint URI needs to be absolute, in compliance with the RFC standards ([RFC3986] Section 4.3.)
Ref link: https://tools.ietf.org/html/rfc3986#section-4.3
Hope this helps provide you with a definite answer.
Additionally, we would recommend you forward any outstanding queries to support@okta.com<mailto:support@okta.com>, should they be support-oriented, or make a submission on our Dev Forum (https://devforum.okta.com/) should you require assistance with building apps and integrating them with Okta.
Kind Regards,
Emilian Aldea
Okta Global Customer Care
Hello,
I understand that the RFC standards require that the redirection endpoint URI be absolute. However,
a)
https://tools.ietf.org/html/rfc6749#section-3.1.2 states "The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request. The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3."
It states the final, effective redirection URI must be absolute. It states that the redirection URI may have been established at client registration OR when making the authorization request.
Other users in this thread are asking for support to have a wildcard for the port part of the URI. As I see it, something like "https://127.0.0.1:*/whatever" is not seen here as a literal URI, but rather as a template that can match multiple actual redirection endpoint URIs, such as "https://127.0.0.1:1234/whatever" and "https://127.0.0.1:5678/whatever". It seems to me that, if Okta were to support such wildcards, as long as Okta ensures that the actual, concrete redirection URI that is used each time is indeed absolute, that would be in compliance with the RFC standards.
b)
As another user pointed out, RFC 8252 "OAuth 2.0 for Native Apps" states in section 7.3 https://tools.ietf.org/html/rfc8252#section-7.3
"The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request."
We're looking for an identity management solution that we can use to implement authentication in our products, which include desktop applications. The current best practices for desktop apps are detailed in RFC 8252. Without a wildcard port, the implementation is simply not possible.
Cheers,
Andreu
Hi
Has any progress been made on this? I'm unable to find the community submitted idea linked elsewhere in this post so don't know what status it is in.
Thanks
Jonny
This idea is related: https://ideas.okta.com/app/#/case/121576
Who cares about some interpretation of a spec? Maybe the spec didn't think about something extremely useful? That's where services (like Okta) should fill the void.
The fact is, this would be extremely useful in a lot of situations, specifically consider review apps that have to assign a unique subdomain. Now I have to pick between Okta or review apps?
A workaround could be authorizing a single endpoint and then within that endpoint redirecting to some wildcard domain, but that adds so much bloat/mess to every single app we develop using Okta... for what? No one is going to make `https://*.*.*/**/*` their redirect URI. If someone adds a wildcard to redirect URIs, just add a significant "Wildcards can be dangerous. Click here to learn more (<-- this is where you can talk about spec stuff). Click here to confirm and live your life." modal or something.