0

Why would an OAuth implementation choose to use the Authorization Code Grant -- when it means that the access tokens are leaked to a third party?

I've been using API keys for a package on my server to communicate with a service provider's API. I recently updated the package, and they no longer support API keys. They're forcing us to authenticate with OAuth 2.0.

Unfortunately, I learned that they're using the Authorization Code Grant with a static redirect uri, which means the redirect uri must be the devloper's server. As a result, this implementation means that the (non-expiring) access token is first sent to the developer's server (where they claim they don't store it), and then it's passed down to my server (where it is stored).

The service provider is claiming that OAuth is more secure than using API keys, but when I setup the API keys, it was me who generated and set permissions of the key. And it was only my server (and the service provider's server) that ever saw the key.

Of course, using OAuth in this way is less secure, because it violates PoLP. The third party does not need my access token, and exposing it to them is an unnecessary security risk. My best-guess is that the service provider's product team is pushing OAuth for a better UX at the expense of security, and I can only guess they chose the Authorization Code Flow because they had already set it up elsewhere, and it was just easier to (ab)use it in this scenario.

In what situation is an Authorization Code Grant appropriate? When would you want to use the Authorization Code Flow (ie: when would it be beneficial to security)?

And in what situation is an Authorization Code Grant not appropriate? When would you want to avoid using the Authorization Code Flow (ie: when would it be detrimental to security)?

Improve this question
5
  • the whole point of OAuth is so that users don't share their credentials (passwords). Instead they authenticate themselves with the 3rd party, and are provided tokens that another site can use on their behalf and with specific granted accesses. So that's the benefit... it's also easier to rotate them and you can do that very often. So it sounds like the API key is akin to a password in your example. Imagine trying to update your API key every 5-15 minutes or so. You would avoid that flow if you can get rid of the 3rd party altogether. Commented Apr 7 at 21:13
  • I think OAuth has other uses though, right? Or are you saying OAuth is completely useless to authenticate into a service that already knows your credentials (eg password)? Commented Apr 7 at 21:16
  • Your description of the Authorization Code Grant makes no sense. You claim that the access tokens are “leaked” through a redirection URL, but the OAuth protocol never transmits access tokens through redirects. The client obtains them directly from the authorization server without any intermediaries. Only the authorization code is transmitted via redirects, but the OAuth specification explicitly requires them to expire (with a recommended lifetime of at most 10 minutes). So either you misunderstand the implementation, or what you're working with isn't actually OAuth. Commented Apr 7 at 21:20
  • In general, this question has the same issues as your last one: You’re unhappy with one particular Oauth implementation, but instead of accurately analyzing and explaining the shortcomings, you make all kinds of statements that are nonsensical in the context of Oauth. So it’s not even clear if you understand the protocol and the implementation. Then you want to discuss the Authorization Code Grant, but how is this supposed to work when your understanding of it doesn’t align with the actual specification? Commented Apr 7 at 21:20
  • I would strongly recommend reading the relevant parts of RFC 6749 as the actual specification of OAuth. Don't rely on blog posts or other unreliable sources. Then try to explain what exactly gets leaked to whom in which step. Commented Apr 7 at 21:28

1 Answer 1

Reset to default
2

In the Authorization Code Grant, the access tokens are not leaked to any third party. After the client has obtained an authorization code through the redirection URL, it makes a direct request to the authorization server and gets the access token in the response. There are no intermediaries. See section 4.1 of RFC 6749 for the details.

You claim that the access token is transmitted through the redirection URL, but this isn't the case for the Authorization Code Grant. Either there's a misunderstanding, or the implementation you're talking about isn't actually OAuth. Only the authorization code is included in the redirection URL. However, the code does expire (with a recommended maximum lifetime of 10 minutes), so this contradicts your description of a non-expiring credential.

If the goal is to prevent the access tokens from leaking, the Authorization Code Grant is actually a great solution, precisely because the access token is never shared with anybody except the client (who is supposed to have it). The only problematic choice would be Implicit Grant which indeed transmits the access token through a redirection. So maybe you're mixing up those two grant types.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.