0

Imagine I host some API. Its exact function is irrelevant to the question, but it needs to have some sort of authorization put in front of it. I want to call Google's APIs, so users can interact with their Google data, so I add the necessary code to my front-end to get an access_token from Google. So users don't have to log in to my app and then into Google, I decide I'll use the access_token from Google to secure my APIs as well.

I register a client with Google and allow users to log in to my web front-end using their Google credentials, and then I keep hold of the access_token and when the front-end makes calls to my API, I send it the Google access_token. My API ignores the audience claim - the token is not issued for my API; Google doesn't even know about my API, only the client for login - and uses the token to decide whether the API call is authorized or not. Perhaps it checks for some particular claim or other in the token.

What security issues are there in this scenario? Assume that this is either not against any Google policy or that I will somehow manage to avoid getting punted for breaking policy.

So far the problems I can see are that I don't know if (or perhaps more likely when) the content or structure of the token from Google will change. Perhaps the claim I look for will be retired by Google and my users will lose access they should have, or perhaps its scope (pun not intended) will be expanded and user who should not have access to something will suddenly gain it unexpectedly. If the structure of the token changes sufficiently, my API may not even be able to understand the token at all. Those on their own seem like a pretty big problem to me, but are there any others that I have missed?

Full disclosure: in reality, I host the IdP and it's an external dev who is using my tokens to secure their API. I wrote the bulk of the post as if I was the one with the API because writing it the other way around got clunky and hard to read. I'm trying to come up with as strong an argument as I can for why they shouldn't be doing what they propose - if indeed there is a problem with it at all.

Richard Ward
  • 194
  • 9
  • If I understand what you said correctly, that'd be cross-domain and wouldn't work. Google's access token would also rotate... a token is not really authentication... it ties to a session with a certain domain. So you can't use Google's IDP without your app/server making a call to Google. Your app/server would have it's own session and token. – pcalkins Jun 13 '22 at 21:05
  • @pcalkins The *client* is known to the IdP; the *API* is not. The client is requesting an access_token from the IdP (and receiving one, as it should), but it's then sending it to an API that is not and never will be an audience in that token. – Richard Ward Jun 13 '22 at 21:53

0 Answers0