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.
Related
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.
In RFC6749#setion-4.1.1 introduces redirect_uri is optional.
But above Authorization Code Flow step (A), (C), (D) and also (E) describes what redirect_uri does.
And especially step (E) describes like following..
and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C).
So I confused when I saw section 4.1.1.
I think maybe this document not wrong, just stupid I did not understand.
Please tell me why redirect_uri parameter is optional.
Thanks in advance.
In rfc6749#section-2, describes:
When registering a client, the client developer SHALL:
o provide its client redirection URIs as described in Section 3.1.2.
in rfc, SHALL means MUST, REQUIRED.
(Key words for use in RFCs to Indicate Requirement Levels)
And let's see rfc6749#section-3.1.2.3 which mentioned by #Florent Morselli.
If multiple redirection URIs have been registered,
if only part of the redirection URI has been registered,
or if no redirection URI has been registered,
the client MUST include a redirection URI with the authorization request using the "redirect_uri" request parameter.
Conclusion
If we provided only one complete redirection uri when registering client, redirect_uri is optional when authorization request.
warning
If the "redirect_uri" parameter was included in the authorization request, you MUST include it in access token request. details here.
The answer to your question is in step (C) (of the same RFC6749#section-4.1):
the authorization server redirects the user-agent back to the client
using the redirection URI provided earlier (in the request or during
client registration).
So if there is no redirect_uri in Authorization Request then authorization server use the default url which have been set during client registration (as described in rfc6749#section-2 which #galcyurio mentioned in his answer).
Also in #section-3.1.2:
3.1.2. Redirection Endpoint
After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to
the client. 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.
I was trying to learn how to implement openID connect in one of my Android app, I came across two terms redirect url and callback uri, I'm not able to distinguish between the two. What exactly is the difference?
The official term is "Redirection Endpoint", see: https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2:
3.1.2. Redirection Endpoint
After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to
the client. 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. The endpoint URI MAY include an
"application/x-www-form-urlencoded" formatted (per Appendix B) query
component ([RFC3986] Section 3.4), which MUST be retained when adding
additional query parameters. The endpoint URI MUST NOT include a
fragment component.
but other terms like "Redirection URI", "Redirection URL", "Redirect URI", "Redirect URL", "Callback URL" and "Callback URI" etc. are all used interchangeably, some because in protocol fields the term gets shortened to things like redirect_uri, others because of inherited legacy terminology from similar protocols that pre-date OAuth 2.0.
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 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.