0

This question is related to the OAuth based login in a native mobile application. As per the Authorization Grant Type flow, the user enters the userid, password in the login page and in response, the Authorization Code is obtained in the URL (since its URL, https based encryption wont work either).

This means that the Authorization code is available in the proxies and anyone can use it, provided they have the client secret as well. The client secret cannot be stored in the mobile application as the mobile app is not considered secured as well.The approach that I had in mind to circumvent the security of client secret was to provide a server side endpoint, where the mobile client can call with Client Id, Authorization code and redirect url. The endpoint will enrich the client secret and then call the actual token endpoint to get the accesstoken. The accesstoken is secured as the entire communication is over HTTPS.

Now the issue is - the authorization code in the URL parameter is insecure and vulnerable. Or am I overthinking about the security. This is the primary question and if this is indeed a security issue, what is the mitigation adopted?

One option that I could think and from one of the older stackoverflow threads was to Secure the token endpoint which will give the access token from the server side. Any suggestion as to how to do that? - If its certificates , then the certificate will be packaged in the mobile app, making it insecure again)

Vaya
  • 560
  • 6
  • 20

1 Answers1

1

Shameless plug ... but since I read through the complete specs and did some offline discussions, I want to provide my view on the same.

a. TLS between client and the authroization server - When the complete authentication is done after few redirects within the authorization provider, the Authorization provider will set the location header as the redirect uri along with the authorization code in the query parameter within he location header. Since the authorization code is within the location header and the response headers are still protected by the TLS, eavesdropping will not expose the authorization code.

b. If the client is a mobile application - the redirect uri should point to a custom URI scheme that will point to the mobile app itself. So when the browser executes the redirection based on the location header, the browser will call the mobile app. The call doesnt go out of the device and hence the authorization code is not exposed to the outside world.

c. If the client is a web application - the redirect uri will be executed over the browser and the authorization code will be exposed in the proxy logs (after https offloading) and in the browser cache or if there is an redirection , it will be susceptible for the leak of the codes. The protection of the authorization code is done in 2 ways - a. The authorization code can be set with a lifetime, which can be small. b. The authorization code can be used only once. So if the actual client already used it, no one can reuse the auth code to get the access token again.

d. Based on the point mentioned by Kris in the comments below, the spec defines an approach to protect the misuse of the authorization code. If the code is used more than once, the Authorization server can revoke all of the access tokens created with the authorization code.

Vaya
  • 560
  • 6
  • 20
  • d. From [the specification](https://tools.ietf.org/html/rfc6749#section-3.1.2.1): The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. – Kris Vandermotten Dec 05 '16 at 09:26
  • @Kris - Agreed that the redirection endpoint is using TLS but the authorization code is part of the HTTP query parameter, which cannot be protected by TLS. – Vaya Dec 05 '16 at 10:24
  • That depends what you mean by "protected". Granted, it may be logged by your web server, and possibly by a proxy if that terminates the TLS. But an eavesdropper on the network can't see it. – Kris Vandermotten Dec 05 '16 at 15:22
  • Furthermore, as you pointed out yourself, [the specification](https://tools.ietf.org/html/rfc6749#section-4.1.2) states "If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code." Since the client will exchange the code for a token as soon as it receives it, either it is the only one having an access token from the code, either nobody has one. – Kris Vandermotten Dec 05 '16 at 15:23
  • Indeed, then this is a race situation. I consider the second point that if anyone tries to get the access token with the same authorization code, the Authorization server should revoke all of the access tokens that was issued by the authorization code . This will fit the purpose. Thanks for pointing it out. – Vaya Dec 05 '16 at 15:33
  • To the last but one comment made by you, the TLS need not be offloaded for an eavesdropper to get the http parameter value. TLS doesnt protect the query parameter passed as URL parameter – Vaya Dec 05 '16 at 15:34
  • What makes you think that? Of course the URL is encrypted. See also http://stackoverflow.com/questions/499591/are-https-urls-encrypted – Kris Vandermotten Dec 07 '16 at 08:26
  • Thanks for the pointer ..i understood that the domain name and port is only open.. all clarified and will update the answer – Vaya Dec 07 '16 at 09:03