(Markus Sabadello)
OIDC AUD – to consider structuring the audience claim of OIDC
I’ve put context, motivation and the definitions of some things on the bottom. The context that the access tokens are more widely passed around the infrastructures compared to other tokens, so whoever gets my access token can impersonate me. Yesterday we had a session where we discussed the MY-token service. I can use one access token to connect MY- token to another token and can then give me new access tokens, which makes it easier to spread tokens around the world. So if my access token is stolen, someone can keep on getting new access tokens. I’ve considered using the audience’s claim to reduce the power of the access tokens.
First of all, there is the RC division and the co division The co division is just there to say that there’s an audience for the ID token and this is not what we’re talking about. We’re talking about the audience defined in the RC. OIDC will be for the first client that gets a token from the OP. This is a delegation scenario. There is no OIDC in there.
The delegation scenario is not well specified, the idea of passing on my token for Google people is not even considered.
What’s in the old claim that can be in the general token? Because if it’s optional, what’s its behavior if it’s not present? In this bank it says “if it’s not there it’s fine”.
The point is that for the JOT specs the sub and the issue are mandatory, all other claims are optional because they depend on whether you need them or not, but you can make them mandatory to have in your profile. It also says that the old claims should contain a string or an Ivalue for the client that is connected to. The principal processing of the claim does not identify itself with the value.
Q: If the claim is not present, then it’s behavior is different? A: Then you don’t need to reject it. If it’s present and the client doesn’t find itself in it, then it has to be rejected. It doesn’t say how the client should find itself in it. It says that it should identify itself. The way it’s written could be interpreted as there could be a host entity ID.
Q: Isn’t the purpose of the audience not so much that the client rejects the token, but that a resource rejects access from a client that is not in the audience? A: Yes. In this scenario, if there is a client, the question is about who the other resources let your client distributes to… and the value to decide to go over here to the left but not over here to the right. The ultimate decision should be that if a client who is not in the audience comes into possession then the access should still be rejected. In the forwarded token might need to have how to move, so that the receiving software, which might be that a library used for clients has to be rejected while in fact it’s supposed to authorize.
You can’t ignore it if there is an audience, because it says “must identify itself” and it says “each principle intended to process must identify itself”, so if you do in the old, the client must be there or it won’t work. The JWT spec is not specific about OL. I presume it would be any participant inflow through which the JWT goes.
So it could also be the resource and not just the client, the resource could try to identify itself. In the OIDC scenario, the protect endpoint would be the user endpoint. In the OIDC case what we have is if a client gets via browser an authorization grant from a user then it gets a token and it checks to see that the token was not intended for this client and can reject it because there was something going on with the redirect or that the user has messed around with the browser. The client is trusted by the OP, it would check whether it should’ve received that token.
But this client can then send this token to some resource, which is not protected.
This is just the principal intended to process a JWT.
It can use this thing but only for the resources intended for the audience.
So a JWT without an audience is kind of a super JWT, which sounds scary. It’s like a standard of D proxy which is not constrained, which is worse because with a proxy you have delegations that you can trace things back to.
Q: So it’s the OP who decides whether they’re gonna issue a super token? A: It’s the client who does it. When they request a token, they specify for which audience.
Q: There should be standardization, when there’s an audience and you want token exchange and you want to get another token, what is applied? A: You want to narrow down the audience, it’s not so specified. Super JWTs are not such a big problem. The client in this case still needs to proof the data and then decides whether to do anything or not. So if it is a valid token and the used info is not in the right group, it still shouldn’t be able to do anything.
If you have scopes and you have an introspection endpoint and then the protective resources connecting to the introspection endpoint, then the OP can still say “no”.
The use case is always satisfied do you need to have a live connection between the protective resources and the introspection endpoint or will they be able to delegate beyond that.
You might not want to go to the OP all the time, you might want to do the offline verification of the token because you have the keys the client has the keys, and check whether the token signature is okay.
There are JWT profiles which are not really RC-specified, and it’s not specified within OL. The only thing that is specified is that you go to an introspection endpoint and you get the info back, but some profiles and people use JTWs, which you can get signed and get something verified knowing it’s intended for you. You can check if your audience is in there, the question is how much you want to restrict it. I think they basically say that we can’t restrict the audience that much because you don’t know where your token will end up.
You want something in the token itself that will be able to constrain.
You can use grouping.
It doesn’t say that my unique name has to be … it can also be a characteristic I am configured with and I don’t know why this list couldn’t contain numbers It can be a number of lists. If you want to implement a number of options like proxy button and constraint you would want to add a new claim.
Q: Talking about JWTs that are assigned by the OP, so you can’t simply modify the tokens. A: No, that’s permanent.
With token exchange, since you get a new token, you can say you can’t further exchange that token. With the standard BARO tokens you can’t do it because it’s signed as such that you can’t change the content. If any specification happens, it should be about a) what action to put in the AUD and b) how to behave on token exchange, if you want to change the AUDs. The macaroons content- you can only narrow it down and cryptographic things are not needed as it’s the OP that decides.
With WLCG, they were using the scopes to limit what they can do. I think it’s rather limited what you can do with it. If you think about grid JWTs. WLCG can’t add anything in Europe. In Europe it can add something, not currently but if you have shared infrastructures. You can not only use it for starting your machine but for accessing your library.
Do we know where the most libraries specified that the client can access it or a list of possible audiences?
It’s a JSON list. There’s an array. A specific case where there’s only one audience.
Q: What about on the client’s side, a client config? A: Not sure about it.
In any case, it would be good to profile it, to agree on what’s valid.
We need to scope them as well in means of shared infrastructure if we start using OIDC as part of computing and is meant for WLSG. Maybe you can buy the audience.
You should make space for documenting what you’re doing.
As soon as it has a proper namespace.
Q: Why does this need to be defined? A: I wondered whether it might be useful, I was thinking about the analogy, extended SAML. Chicago use case with a proxy, and the thing in the middle wasn’t a SAML entity. the policy around managing the style of authentication. What’s different here is that you have clients, which is more of an entity that builds how to interact with the protocol, you need to use resources that are protocol conformant. It gives you another idea how to constrain delegation by thinking about the different functional actors and each of the elements in the architecture.
The way it works with the BARO tokens, unless you would do a token exchange, I don’t see how you could constrain that. Concerning the consumption of the end service, the principle, there have been parsing JWTs and parsing the audiences should not be that hard.
It’ll be good to check what is possible in the token exchange. Coming back to your question, just to narrow the scope, some people think you can only harm one infrastructure and not both.
Q: The SAML thing is part of the SAML SEP, right? A: Talking about strings, the intention is to be something more dynamic like putting more dependencies. Like a life audience. This token can identify itself but how it works is unspecified.
The goal of the session is brainstorming. I think we should bring it up in the WSP working group. It was a thread on GitHub with a request to an agent. We thought, when we have this token renewal, we should reduce the power. There should be a form of delegation. WLCG - formula use cases are broader. All use cases are what used to be called grid cases. A lot of institutions have that kind of infrastructure. We are hoping to use OIDC agent .. people accessing SAML resources, the keep lock seems to use the audience by default. You have to request token permission to access clients. You can also use IRIS.
