Discover access token audiences #17469
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NobodysNightmare
force-pushed
the
discover-audiences
branch
3 times, most recently
from
d31e204 to
efc65c8
Compare
| # + | ||
|
|
||
| module OpenIDConnect | ||
| class ProviderTokenParser |
There was a problem hiding this comment.
I am starting to become unhappy about names.
I called the UserToken like that, because it's a token that grants access in the name of the user.
I called the ProviderTokenParser like that, because it only allows proper parsing of JWTs that were issued by a configured provider (they are not parseable without knowing the provider).
But now looking at both names next to each other, it doesn't seem to make sense, because there are no tokens to do stuff in the name of a provider. It seems counter intuitive, that the ProviderTokenParser would parse a UserToken and yet that's what it does...
NobodysNightmare
force-pushed
the
discover-audiences
branch
2 times, most recently
from
d4c2af6 to
178b622
Compare
NobodysNightmare
force-pushed
the
save-oidc-tokens-to-open-project-database
branch
from
1ab8a1c to
06f4d7d
Compare
JWT parsing is rather involved, because we need to fetch proper certificates first. We will need to parse JWTs in a different context than authorization as well, so it makes sense to have the parsing centralized. This also allowed to add specs for this previously not (unit) tested piece of code.
NobodysNightmare
force-pushed
the
discover-audiences
branch
from
178b622 to
0411a3d
Compare
We want to know for which purposes tokens can be used. Assuming that we receive JWTs as access tokens, it's possible to read their audience and thus check where these tokens are usable. Importantly, it's still possible that an access token is not a JWT, so we have to allow that as well. The code could be extended in the future to send such tokens to the introspection endpoint of the IDP, hoping to receive an audience list as a result of that.
NobodysNightmare
force-pushed
the
discover-audiences
branch
from
0411a3d to
555e27a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket
https://community.openproject.org/projects/cross-application-user-integration-stream/work_packages/60162
What are you trying to accomplish?
This PR is an extension of previous work in #16940. We want to be able to use tokens stored in the corresponding database model for access to third party services, such as Nextcloud.
There are different ways that we can use these existing tokens for that. The case handled in this PR is that the token might already be immediately usable for use in certain services, which we can discover from the token's audience.
What approach did you choose and why?
We are expecting the access token to be a JWT that we can parse and verify using the metadata we have configured for the corresponding OIDC provider. While there is no guarantee that access tokens can be parsed as JWTs, it's very common to find when dealing with an OIDC IDP, since those are required to provide their ID tokens as JWTs, so the "infrastructure" for signing JWTs exists anyways.
To perform the parsing I extracted previously existing code from the
JwtOidcwarden strategy into a new parser service and adapted it to the common needs of the warden strategy and our new code.Merge checklist
Added/updated documentation in Lookbook (patterns, previews, etc)