CODEWITHSUNDEEP
oauth-2.0jwtmicroservicesopenid-connect
Andy N
Andy N

Reputation: 1304

JWT access tokens: a contradiction?

I'm attempting to implement a security solution for a micro-services architecture. My authentication server supports OAuth2 and OIDC.

I'm trying to figure out if I can pass a JWT token between my micro-services to avoid having to repeatedly exchange an opaque token to get the user's claims. There's nothing (practical) that stops me doing that. I can:

I've read that it's ok for an access token to be a JWT.

Great, but:

should I?

My (moral?) issue is this:

A JWT is intended for a specific audience. In fact the spec basically says that if it's not for you, you should reject it.

A Bearer token is intended to be non-audience specific. So if I issue a token that says that the bearer can read my mail, it can get passed through half a dozen different services, any one of which should be able to read my mail.

So my question is simply, how can a JWT be a bearer token?

Bonus points for links to any nice articles/videos/examples of an effective distributed authentication solution!

Upvotes: 2

Views: 590

Answers (1)

fiddur
fiddur

Reputation: 1857

A JWT is intended for a specific audience. In fact the spec basically says that if it's not for you, you should reject it.

This is the case also for a bearer token. It can be passed on by anyone, but only the audience should act on its validity.

So, service X can get a JWT bearer token with intended audience service Y. It will not give the calling client any authorization based on that, but calling service Y with it does not violate the audience claim. What would violate the audience claim is if service X validates the JWT, seeing the mismatching audience and says "Well, since the client has a JWT stating that it is user Fubar, I can return some info about user Fubar.".

The difference for an opaque non-JWT bearer token is that service X would have no way to misuse it...

Upvotes: 1

Related Questions