I'm trying to configure a new Okta application with a callback URL that will depend on the tenant's subdomain. Meaning I need the same Okta app to accept redirection (using the redirect_uri parameter) to https://0001.my.domain.com/oauth2/callback, https://0002.my.domain.com/oauth2/callback and so on. Notice the 0001 and 0002 subdomains. This may seem strange, but it's for demo purposes. The point is to avoid having to set up a different Okta app per tenant.
Okta's own docs on the subject read:
Does your Initiate Login URI vary by tenant? — If Yes, enter which part of the Initiate Login URI is customizable. For example, the subdomain in https://<subdomain>.example.com/signin/.
However, when I try to do this I run into an error complaining that:
The redirect URIs must be absolute URIs.
Maybe I'm just reading this wrong, but I take it to mean that variables/placeholders are supported.
I've searched the rest of the Okta docs but found no additional information on the subject.
If Okta let you do this, it would not be OAuth 2.0 compliant.
See https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-16#section-2.1:
When comparing client redirect URIs against pre-registered URIs, authorization servers MUST utilize exact string matching except for port numbers in "localhost" redirection URIs of native apps.
Related
I'm trying to learn about OAUTH and OpenID Connect.
Thus I am investigating my own traffic, listening to Authorization Requests and Grants by checking for required parameters in OAUTH as described in https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 and https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2 for the Authorization Code Flow as well as described in section 4.2.1 and 4.2.2 for the Implicit Flow.
Unfortunately, by using the SSO option for Google on joinhoney.com, I am only able to catch the Request, but not the Authorization Grant.
So, while debugging and having a look at the actual request, I can see the following parameters in the query part of the url:
Parameter
Value
redirect_uri
storagerelay://https/www.joinhoney.com?id=auth[censoredID]
response_type
permission id_token
scope
email profile openid
openid.realm
client_id
705229005811-2fdpup66d8aefq4qs2ru1n8qiosuq4fb.apps.googleusercontent.com
ss_domain
https://www.joinhoney.com
fetch_basic_profile
true
gsiwebsdk
2
Now, to get to the actual question:
Where can I find some specified information about the ss_domain parameter?
I could not find any information in https://www.rfc-editor.org/rfc/rfc6749 as well as on https://openid.net/, however when using google, I can find some people using the ss_domain parameter (only without further explanation), so I doubt it is something only used by joinhoney.com.
Would be happy if somebody could bring some light in here!
Thank you!
If you are at www.example.com, and you your redirect_uri is to a different domain e.g. subdomain.example.com, you need to set ss_domain to https://subdomain.example.com.
This custom ss_domain change, however, is not possible using the Google login client side sdk. You got to push the url manually.
I am using the implicit client in the identity server, in the other hand there is a native android app,
My security concerns is:
1- App reverse engineering: if the attacker get access to the client_Id
, redirect_uri and/or response_type, he will be able to mimic the login request.
by doing this he is impersonating the original client
2- Man in the middle: those client_id,... is send to the identity server through the https URI which is not encrypted, why not hiding them in the Header?
3- Browser will resend the token in the URI revealing it to the man in the middle if the redirect URI is not oob or localhost, the browser default behavior is redirecting to the Location, so can we force the developers when they register a client to use oob,
You can say ohh no the app is reading the token and close the browser so fast, before the browser sends the request,
Can we really rely on the app speed of closing the browser, this is sounds squishy?
Which question is legitimate concerns and which is not, also how to solve the legitimate concerns.
About point 1: how google is protecting it's services like google Map, the client Quote is vital and it has to be very secure, Right !!?
Edit
if we pass the client_id in the header to encrypt it, we will violate the http 1.1 spec and oauth2 spec, still we didn't do much, because the client_id is reside inside the handset, by small reverse engineering you can get it
Regarding point number 3:
The token response after a successful authentication will be something like this:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
The user-agent will redirect to the URL provided in the location parameter. Here there is no need to worry about MiTM attacks because the access-token is included in the URL hash fragment & hash fragments are not sent in the HTTP request messages, in other words the hash fragment will not leave the client machine.
Yes, but the token service will only return the user to the pre-registered callback uri for the client.
2 & 3. You should use HTTPS for most everything on the web these days.
I am getting the Invalid Redirect URI while trying to authenticate. This is the first step to authenticating on the guide and I have literally copy-pasted the code into my browser and subbed in my Application Domain and Application ID and it says Please enter a valid redirect_URI. https://connect.deezer.com/oauth/auth.php?app_id=MyAppID&redirect_uri=MyRedirectURI
I had the same problem until I found out that unlike any other music streaming service, Deezer does not allow (or it's a bug) redirect uris that
contain a port like localhost:9000/deezer/callback
have a subdomain like cheapuri.noip.me
I guess co.uk then won't work either
It seems that the only thing that is working are "normal" uris like api.com.
The way I work around this when developing:
Let Deezer redirect you to some non existing uri, then change the uri in the browser bar.
I would double check that the redirect_uri in your /oauth request URL matches exactly that which is referenced in your oauth configuration/whitelist settings for Deezer.
Even the smallest difference like http vs https or including wwww., etc. can throw an error. You might find some of the tips in this OAuth Troubleshooting Guide helpful for other common OAuth errors to check, too!
The first item in that guide covers some common invalid redirect errors.
I was wondering why we need to specify the redirect uri both in our code and in google developer console when using Oauth2.I was following this tutorial http://www.tothenew.com/blog/grails-way-of-oauth-2-0-to-access-google-apis-part-1/.
The client may register multiple redirect_uri's with the Authorization Server (i.e. Google) and sending the redirect_uri in the request itself is to let the Authorization Sever know on which one of the registered redirect_uri's the client wants to receive the authorization response.
The redirect_uri parameter is optional by spec: if there's only one registered, then the redirect_uri parameter may be omitted from the request.
The only redirect URI which really matters is the one which you enter into your Google Developer Console. This redirect URI is what Google will use to reconnect with your web application after it has either approved or rejected your authorization attempt.
The reason you are also specifying this redirect URL in your code is to ensure that your application can correctly recognize the incoming redirect request.
My question may seem silly, but I really do not understand - what the purpose of catching redirect_uri from request and compare it with URI specified in the clients table? Is it due to a security issue?
Pre-registering redirect URIs itself is a security measurement because the authorization requests in OAuth 2.0 are not signed. Attackers could phish the user in clicking a link that would result in an authorization request with a redirect_uri pointing to a site that they control.
Sending the redirect_uri in the request itself does not serve a security purpose but is just there to let the Authorization Sever know where the client wants to receive the authorization response in the case there are multiple redirect URIs registered for this particular Client.
The redirect_uri parameter is optional by spec anyhow. If there's only one registered, then the redirect_uri parameter may be omitted from the request. If multiple redirect URIs are registered and no redirect URI is provided in the request, the result is unspecified: the AS may pick the first, anyone or none of them.