As an example, let's look at how authentication works with Kubernetes:

enter image description here

Specifically, let's focus on what the api server does. To authenticate the request, it:

  1. Verifies that the JWT signature is valid
  2. Checks that the JWT isn't expired
  3. Checks that this user is authorized to use this API

There must be more to it than this! The thing about OIDC providers is they will hand out tokens with valid signatures to just about anyone. For example let's say I want to use Google as my identity provider. If the only requirement were that the JWT signature is valid, an attacker could set up some site I might like, say with funny cat pictures. At some point I visit the site and log in, and bingo, attacker has an identity JWT with a valid signature and my name on it. It would be Pretty Bad if the owner of funnycatpictures.com could now access the Kubernetes API server under my name.

So what specifically are the constraints that prevent this attack?

My understanding is the aud (audience) claim in the JWT is part of it: Kubernetes must accept the token only if aud contains its OAuth client ID. This should mean tokens issued to other OAuth clients (like the funny cat pictures site) won't be accepted because they will have the wrong aud.

However, there seems to be a way around this with the implicit grant flow, which doesn't require an OAuth client secret. As such, funnycatpictures.com could use the implicit flow but with the Kubernetes client id, thus obtaining tokens with the correct aud which would be accepted by the Kubernetes API server.

What prevents such an attack?

  • This is not possible. The Oauth Provider checks if the redirect URI of the client ID matches with the configured redirect URI so malicious clients cannot replace redirect URI with their own endpoint URL if they are using stolen client ID for implicit flow.
    – defalt
    Jul 24, 2023 at 15:57

1 Answer 1


Scope. Cat pictures would not be granted the ability to request the scope for your API and thus not be able to access it with any resulting access token. Also, in the implicit flow the callback url is registered against the client and must match exactly.

  • When you say "not be granted the ability to request the scope for your API", what's that mean specifically? How is that ability granted? By whom? How? When? How does the oauth provider know it's Cat Pictures making the request?
    – Phil Frost
    Sep 18, 2018 at 0:51
  • Cat pictures is the client and clients can only ask for scopes that client has been given explicit access to by the IDP administrator when the client was configured prior to use. The provider knows it’s cat pictures because of the client ID passed in the request.
    – mackie
    Sep 18, 2018 at 7:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .