Enhance id_token with custom claims about oidc HOT 7 CLOSED

@michaelholtermann Would the API discussed in #323 help you?

We get similar feedback from other users. Basically, our storage interfaces are an abstraction of what we thought we needed for Zitadel. But, might be too restrictive for other implementations. Therefore we are open to increasing the data passed to the storage interface API.

For example, currently we discard info that is available in the incoming HTTP request, which we know we already have in the database (zitadel), so we prefer to use our own state over the state in the request. However, this solution might not be suitable for others.

After some internal discussions, we came to the agreement that it doesn't harm to pass a bigger data object to the storage layer, like an AuthRequest, TokenRequest or more. For Zitadel that would mean we just extract the needed data from there.

Please note that we open to this kind of changes, but they are not on our list of priorities. As this is also an open source project, we are open to contributions through PR. For changes to the package API, I would suggest to make a complete proposal in an issue first.

This must be done backwards compatible, of course.

Breaking changes are allowed and should target the next branch. Currently we are working towards a v3 release.

from oidc.

@livio-a Can you have a look at this?

from oidc.

Hey @michaelholtermann

I'm not totally sure if I got you correct and have some questions:

What do you mean by some token, but not OIDC compliant?
Because you write, that you can call the legacy system with that secret and reveal things like user name, mail address, roles etc.. This is sound like an access token. Which leads me to the second question: Why do you need to wrap it into the id_token?
IMO the id_token should only be used for identification and not used to access an API / resource server.

Regarding custom claim in id_token. There's already a possibility using scopes (there's also one for JWT access tokens):

E.g. in ZITADEL we use it to configure it roles should be in the token:
https://github.com/zitadel/zitadel/blob/main/internal/api/oidc/client_converter.go#L72

... and we set some scopes depending on the project / client:
https://github.com/zitadel/zitadel/blob/main/internal/api/oidc/auth_request.go#L27

Assertion of the roles into the id_token / userinfo response:
https://github.com/zitadel/zitadel/blob/main/internal/api/oidc/client.go#L290-L296

And special case for PAT (personal acceess token), were we automatically assert some scopes on the introspection,
so that custom claims will be returned
https://github.com/zitadel/zitadel/blob/main/internal/api/oidc/client.go#L186

Hope this already clarifies it a bit. Looking forward to your answer.
I'm sure we'll find a solution for your case.

from oidc.

HI @livio-a.

thanks for the reply. I'm sorry if my request sounds somehow weird. I'm not happy with our current solution, but it's a legacy system I have to live with.

What do you mean by some token, but not OIDC compliant?
Because you write, that you can call the legacy system with that secret and reveal things like user name, mail address, roles etc.. This is sound like an access token. Which leads me to the second question: Why do you need to wrap it into the id_token?

Technically, it's some base64 encoded JSON that does not contain any useful information for me as the caller. It's behavior is more like an API key, that is, I can call other endpoints with it of that legacy system to reveal something useful. For example, I can query the PII of the original user by calling a certain endpoint with that token, or upload some data to that system with the same token.

But I cannot interpret the contents of this token, or rebuild it later.

I try to isolate that behavior of the legacy system as far as possible. In my own system, I would like to go fully into OAuth2/OIDC. But often I have to call that legacy system later, for which I need it's original token.

My whole system consists of several micro services which I like to protect with standard compliant OAuth2, and that big ol' legacy system which is integrated tightly into several processes and which in fact owns the user base.

I hope this make my idea more clear, but I'm happy to discuss further :-)

Thanks again!

from oidc.

@livio-a can you have a look at this again?

from oidc.

As we didn't hear back and the api that @muhlemmer mentioned above has been merged I will close this issue.
Feel free to reopen if its not solved, or more information can be provided

from oidc.

@hifabienne @muhlemmer I'm sorry, I totally forgot about this issue, my priorities shifted slightly :-/

Thank you guys for sharing ideas! I hope I can pick them up again in the future.

from oidc.