🚀 Feature: include extra information in access token #79

New Issue

OVERLORD · 2025-10-07T00:00:56+03:00

OVERLORD commented

2025-10-07 00:00:56 +03:00

Originally created by @peterforeman on GitHub.

Feature description

Allow extra claims to access token.

Pitch

I'm trying to get RabbitMQ working with Pocket-ID, but unfortunately their implementation only makes use of the access token. Other SSO providers like Zitadel or Authentik have the option to include extra data in the access token. In Pocket-ID I cannot find such feature.

From the RabbitMQ docs:

Authorization Flow

This plugin does not communicate with any OAuth 2.0 provider in order to authenticate user and grants access. >Instead, it decodes an access token provided by the client and authorizes a user based on the scopes found in >the token.

[snip]

The token can be any JWT token which contains the scope and aud fields.

In chronological order, here is the sequence of events that occur when a client application wants to connect to >one of the RabbitMQ's messaging protocols, such as AMQP:

The Client application requests an access_token from the OAuth 2.0 provider.

The access token must include scopes supported by RabbitMQ in the scope field (it is possible to use a different field for the scopes by setting the name of the new field in auth_oauth2.additional_scopes_key).

The Client application passes the token as password when connecting to RabbitMQ's messaging protocol. The username field is ignored.

RabbitMQ validates the token's signature. To validate it, RabbitMQ must have the signing keys or download them from the JWKS endpoint as explained in earlier sections.

RabbitMQ validates that the token has the audience claim and whose value matches the resource_server_id (this operation can be deactivated by setting auth_oauth2.verify_aud to false).

RabbitMQ translates the scopes found in the token into RabbitMQ permissions (the same permissions used in the RabbitMQ's internal database).See above

There are probably more applications that want extra claims in the access token since the big SSO providers have this option as well.

Originally created by @peterforeman on GitHub. ### Feature description Allow extra claims to access token. ### Pitch I'm trying to get RabbitMQ working with Pocket-ID, but unfortunately their implementation only makes use of the access token. Other SSO providers like Zitadel or Authentik have the option to include extra data in the access token. In Pocket-ID I cannot find such feature. From the RabbitMQ docs: > Authorization Flow > >This plugin does not communicate with any OAuth 2.0 provider in order to authenticate user and grants access. >Instead, it decodes an access token provided by the client and authorizes a user based on the scopes found in >the token. > >[snip] > >The token can be any [JWT token](https://jwt.io/introduction/) which contains the scope and aud fields. > >In chronological order, here is the sequence of events that occur when a client application wants to connect to >one of the RabbitMQ's messaging protocols, such as AMQP: > >The Client application requests an access_token from the OAuth 2.0 provider. > >The access token must include scopes supported by RabbitMQ in the scope field (it is possible to use a different field for the scopes by setting the name of the new field in auth_oauth2.additional_scopes_key). > >The Client application passes the token as password when connecting to RabbitMQ's messaging protocol. The username field is ignored. > >RabbitMQ validates the token's signature. To validate it, RabbitMQ must have the signing keys or download them from the JWKS endpoint as explained in earlier sections. > >RabbitMQ validates that the token has the audience claim and whose value matches the resource_server_id (this operation can be deactivated by setting auth_oauth2.verify_aud to false). > >RabbitMQ translates the scopes found in the token into RabbitMQ permissions (the same permissions used in the RabbitMQ's internal database).See above There are probably more applications that want extra claims in the access token since the big SSO providers have this option as well.

OVERLORD closed this issue

2025-10-07 00:00:59 +03:00

OVERLORD commented

2025-10-07 00:01:00 +03:00

@peterforeman commented on GitHub:

other OIDCs allow javascript / custom code to implement this.

The problem with this would be requiring executing custom code (i.e. untrusted) within Pocket ID. It can be done, but it does come with significant challenges in terms of maintenability and security.

Agreed. Then an API like your proposal would be better.

@peterforeman commented on GitHub: > > other OIDCs allow javascript / custom code to implement this. > > The problem with this would be requiring executing custom code (i.e. untrusted) within Pocket ID. It can be done, but it does come with significant challenges in terms of maintenability and security. Agreed. Then an API like your proposal would be better.

OVERLORD commented

2025-10-07 00:01:00 +03:00

@peterforeman commented on GitHub:

#781 would fix this if we would also allow access token to have custom claims, closing this one.

@peterforeman commented on GitHub: #781 would fix this if we would also allow access token to have custom claims, closing this one.

OVERLORD commented

2025-10-07 00:01:00 +03:00

@ItalyPaleAle commented on GitHub:

other OIDCs allow javascript / custom code to implement this.

The problem with this would be requiring executing custom code (i.e. untrusted) within Pocket ID. It can be done, but it does come with significant challenges in terms of maintenability and security.

@ItalyPaleAle commented on GitHub: > other OIDCs allow javascript / custom code to implement this. The problem with this would be requiring executing custom code (i.e. untrusted) within Pocket ID. It can be done, but it does come with significant challenges in terms of maintenability and security.

OVERLORD commented

2025-10-07 00:01:01 +03:00

@ItalyPaleAle commented on GitHub:

Would #781 address this too?

@ItalyPaleAle commented on GitHub: Would #781 address this too?

OVERLORD commented

2025-10-07 00:01:01 +03:00

@peterforeman commented on GitHub:

I think it would, although I'm not sure if using a HTTP(s) backend would we a industry-standard approach. But I'm not really into OIDC so am unable to tell.

I did some own tweaking with custom claims and that worked. The approach was adding custom claims to the user and let these get added to the access token. Then you can use the API to add/change/remove claims from the user.

But indeed: other OIDCs allow javascript / custom code to implement this.

@peterforeman commented on GitHub: I think it would, although I'm not sure if using a HTTP(s) backend would we a industry-standard approach. But I'm not really into OIDC so am unable to tell. I did some own tweaking with custom claims and that worked. The approach was adding custom claims to the user and let these get added to the access token. Then you can use the API to add/change/remove claims from the user. But indeed: other OIDCs allow javascript / custom code to implement this.

OVERLORD referenced this issue

2025-10-07 00:14:57 +03:00

🐛 Bug Report: updating from 0.19.0 to 0.20.1 yields "Failed to lookup Client-side Discoverable Credential: record not found" errors #435

OVERLORD referenced this issue

2025-10-07 00:15:01 +03:00

🚀 Feature: Add external postgres database support #437

OVERLORD referenced this issue

2025-10-07 00:15:02 +03:00

🚀 Feature: Add external postgres database support #437

OVERLORD referenced this issue

2025-10-07 00:25:14 +03:00

[PR #79] [MERGED] feat: add support for Postgres database provider #952