Private claims implementation#1122
Conversation
skroczek
force-pushed
the
wip/private-claims
branch
from
53464ee to
108b1ee
Compare
skroczek
force-pushed
the
wip/private-claims
branch
from
59da0e0 to
8dd31f5
Compare
|
I have left a few comments inline for the things that popped out. We have not yet fully tested this implementation, will report the results as we go, but this looks great overall. I have been looking into standards around this, and haven't found much: OAuth spec doesn't specify what would be used as a token, thus it doesn't contain any requirements or restrictions regarding the claims we can add into JWT. It seems logical that the library itself wouldn't impose any additional restrictions, so in my opinion the ClaimEntityInterface is rightfully very generic. I've surveyed a few other popular oauth2 server frameworks that support to adding custom claims within OAuth:
To sum up the approach taken in this PR seems reasonable to me, is on par with the capabilities of other libraries and does not violate any existing standards or RFCs as far as I could see. |
|
Thank you very much for the close look and for the feedback. I have already answered to a few points. The suggestions all make sense to me, so I will implement them over the next days. |
|
@skroczek do you need any assistance implementing/testing your changes? |
|
@Pchelolo It took me a while to find time to take care of it. But I think I've implemented all your suggestions except for the two tests. Thanks again for your suggestions and your patience. If you notice anything else, feel free to bring it up. |
|
Thanks a lot and sorry that some of the suggestions didn't make sense. The CI seem to be failing. We will test the new version out and I'll share the results |
|
Hello folks. Is this PR likely to be merged soon? I think it would help me with a problem I am facing. |
|
No timescale on this I'm afraid. It will be done as soon as I get time but there is a lot to check. |
|
Sorry for bumping this but is this PR still alive? I was hoping this could be merged for or before 9.00. I'm happy to help if required. I'm asking to know if I should wait on an official implementation or just roll out my own like many have done by overriding the library. |
|
We are now using zitadel as our IDP for various reasons. We have also switched from PHP to Go as our main language. Because of this, I unfortunately have neither much time nor interest to take care of it anymore. Nevertheless, this remains an excellent library. I will of course leave the PR open so that it can be merged with the repository if desired. |
|
@Sephster any news? |
|
Hi, is this PR likely to be merged soon? |
|
Would also like to know why this is "ignored"? Custom claims are perfectly normal |
|
@Sephster is possible merging or rebasing this with master? |
|
@Sephster hi, we would love to have this feature This is the PR with the most comments Thanks |
|
|
||
| $privateClaims = []; | ||
|
|
||
| if ($this->claimRepository !== null) { |
There was a problem hiding this comment.
First of all, sorry for the (very) late comment. But just got an email that people are interested again.
Maybe just personal preference, but checking if something is not null is not actually checking anything (because it can be ANYTHING at this point).
I'd rather check if it is what I want it to be, e.g. an instanceof check.
thephpleague:9.0.0-WIP -> skroczek:wip/private-claims Upstream merge and conflict resolve
In order to migrate, we need to re-implement two things:
- Issuer ('iss') claim
thephpleague/oauth2-server#1138
This is easy: as advised on the pull request, we can just override
AccessTokenTrait::convertToJWT() to do what we want. In fact, we
already do this to change some other claims, so to avoid rewriting
our code, we just need to add the field/setter/getter matching the
rejected pull request.
- Custom claims
thephpleague/oauth2-server#1122
This is a bit trickier, since we need to know the grant type
in order to generate our claims, and we don't know that in
AccessTokenEntity. I added overrides to do it in the Grant classes
that we use instead, in the method where the AccessTokenEntity
is created. Then we add the field/setter/getter and a minimal
ClaimEntity class matching the stalled pull request.
The licenses of league/oauth2-server and this repository are not
compatible, so I re-implemented the necessary features and did not
copy the code.
Depends-On: I37f0e614f088ab962d7064f2c7f763060283adae
Bug: T261462
Change-Id: I5e8bcbe46b2d4aa8550beb7731aa2a1a70ecc139
* Update OAuth from branch 'master'
to 03670b2329f56a4b1535b2e53c43f17fe6ed39f8
- Migrate from wikimedia/oauth2-server fork to league/oauth2-server
In order to migrate, we need to re-implement two things:
- Issuer ('iss') claim
thephpleague/oauth2-server#1138
This is easy: as advised on the pull request, we can just override
AccessTokenTrait::convertToJWT() to do what we want. In fact, we
already do this to change some other claims, so to avoid rewriting
our code, we just need to add the field/setter/getter matching the
rejected pull request.
- Custom claims
thephpleague/oauth2-server#1122
This is a bit trickier, since we need to know the grant type
in order to generate our claims, and we don't know that in
AccessTokenEntity. I added overrides to do it in the Grant classes
that we use instead, in the method where the AccessTokenEntity
is created. Then we add the field/setter/getter and a minimal
ClaimEntity class matching the stalled pull request.
The licenses of league/oauth2-server and this repository are not
compatible, so I re-implemented the necessary features and did not
copy the code.
Depends-On: I37f0e614f088ab962d7064f2c7f763060283adae
Bug: T261462
Change-Id: I5e8bcbe46b2d4aa8550beb7731aa2a1a70ecc139
11 participants
This PullRequest should implement private claims as described in RFC7519 in section 4.2. According to #1120 , this is still missing, but is wanted.
This implementation is based on that of scopes, which is basically also only a (registered) claim.
I don't think the implementation is finished yet. There are a few questions open
and the testing is still missing completely. But the code works and can already be used for evaluation.One open question is whether the claims should be checked for registered claims before the token is generated. If so, we would have to think about how to react in case of a violation. Will the claim simply be ignored, or should an exception be thrown?
About the testing: I have already looked at the test suite, but I'm not quite sure where and how to put it there.A suggestion would be very welcome.In general I would be very happy about feedback.