Who is reponsible for redirect in OAuth

Question

How does the redirect in OAuth with IdentityServer4 work in detail? Calls the identity server the redirect URL directly (in case of loopback likely not possible) or does the browser get a response from Identity server with the redirect as parameter and the Browser does the redirect?

Is there a known issue that the response of the identity server can be changed to redirect to an other site? So can steal the authentication code.

score 1 · Answer 1 · answered Jan 23 '20 at 13:01

1

IdentityServer4 redirects in the browser. Yes, there is a known issue that response of identity server can be changed to redirect to an other site. There are also ways to mitigate those risks. You can use PKCE and nonce.

https://auth0.com/docs/flows/concepts/auth-code-pkce https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce

answered Jan 23 '20 at 13:01

andrija

1,057
11
21

I use the Authorization Code Flow with PKCE. Nonce is only for implicit grant I think? – Mustafa Jan 23 '20 at 13:48
You can use Nonce in Authorization Code Flow too. It is not mandatory as in Implicit grant, but you can also use it. It can help in preventing replay attack. I use everything in my Authorization Code Flow: PKCE, Nonce and State. – andrija Jan 23 '20 at 14:10
1

Essentially PKCE is there to bind auth. code request to token request. So public clients can't steal tokens. Nonce is there for CSRF attacks. The OP's original question target on redirect URL manipulation. Anyway they all have some connections. – Kavindu Dodanduwa Jan 23 '20 at 14:33
There is no any good reason not to implement all of them. PKCE is a little bit more complex, but it is a must in authorization code flow, Nonce is simple and easy to implement and I need state to restore my own state and keep my api stateless. – andrija Jan 23 '20 at 15:16

score 1 · Answer 2 · edited Oct 07 '21 at 11:19

Rather than redirecting to another to a malicious endpoint (which will expose authorization code), higher probability is to have a Cross-site request forgery (CSRF) attack. For this OAuth 2.0 spec provide you with state parameter (more on this).

Regarding possibility of redirecting to a malicious endpoint, for this to be done,

Your original request must contain redirect url of malicious endpoit
Identity server must validate this url and then decide to perform the redirect

The second point is difficult to exploit (but possible). Because from OAuth 2.0 definition you register redirect URL when you register your 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.

So this means your identity server has been breached OR your registration was exploited. And you will have to worry about user being redirected to a malicious website, which could extract other important details rather than exposing authorization code.

This is emphasised in specification under Authorization Code Redirection URI Manipulation

An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker's user-agent is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client.

Who is reponsible for redirect in OAuth

2 Answers2