Introduce Client Credentials grant#29
Introduce Client Credentials grant#29ctriant wants to merge 10 commits intoIdentityPython:developfrom
Conversation
|
Client Credentials is a pure OAuth2 flow. There is no user involved at all. The library is about OIDC and assumes that there will always be an authentication event, thus a grant is always connected to a user-session/user-id. Having the |
| sid = _mngr.create_session( | ||
| authn_event=_authn_event, | ||
| auth_req=req, | ||
| user_id=req["client_id"], |
There was a problem hiding this comment.
@rohe @peppelinux the client credentials flow is a pure OAuth2 flow. It does not involve a user. A client authenticates and requests an access token from the AS. The client could be an internal service scheduled to get an access token every hour, in order to invoke another service/RS to ensure that it is alive or serving "the right thing".
The approach of idpy-oidc is that there is always a user involved (the library is called oidc after all..) and thus a session is bound with a user_id.
For client credentials, since we have to set something as the user_id, we set the client_id. It is not an actual user (semantically), but it is a user in the sense that it is the subject that made the request. I am not sure if this is the best approach, or if it would be better to have the user_id just be None (and what that could cause in other parts of the system).
You should have more insight on how this should look like.
There was a problem hiding this comment.
client credentials is OAuth2 and we may consider the value of sub that's the resource owner, that in oidc is the user and in oauth2 is the client (RP)
There was a problem hiding this comment.
Don't be mislead by the name. idpy-oidc supports both oauth2 and oidc.
If we keep the triple (user_id, client_id, grant_id) then having user_id being equal to the client_id is much better than having None are client_id.
This is all about storing access tokens somewhere it's not about session management ?
Have to think about what it would take to allow a tuple with 2 values instead of 3 as key.
There was a problem hiding this comment.
having user_id being equal to the client_id is much better than having None are client_id.
Intuitively, I also think this is better.
Have to think about what it would take to allow a tuple with 2 values instead of 3 as key.
If we can get away from that by just using the client_id as the user_id then let's do it. I don't think we have (at the moment at least) any other case where there is no user involved, nor are there plans to have any other such flow. If this comes up we can dive into refactoring the code properly.
There was a problem hiding this comment.
I can live with that.
Even so, I'll probably have a look at how hard it would be to refactor.
|
I've refactored SessionManager. Moved the basic stuff into GrantManager and Database in such a way that the impact on |
Signed-off-by: Kostis Triantafyllakis <ctriant@admin.grnet.gr>
Introduce revocation endpoint See merge request eduteams/proxy/idpy-oidc!2
ctriant
force-pushed
the
feature-client-credentials
branch
from
cefce13 to
803fc36
Compare
|
Accomplished through another PR (#58) that has been merged in develop |
4 participants
This MR introduces the Client Credentials grant as described in rfc6749.
Following the example of
TokenExchangeHelper, aCCAccessTokenHelperis added, that handles client credentials requests.In the case of the Client Credentials grant a client can request an access token using only its client credentials, thus there is no
user_idto associate the new grant.In this MR, there is an assumption that
user_id == client_idduring the creation of the new grant. Is there any other idea about how we could deal with this issue?