Client Registration issue with Bearer Header/Body #54

Activity

1. rohe commented on May 14, 2020

   

   rohe

   on May 14, 2020

   Contributor

   More actions

   What does the token contain ?
   Since this is at the registration endpoint, the client is not registered so there can be no reference to client information (like client_id/client_secret or keys).
2. angelakis commented on May 14, 2020

   

   angelakis

   on May 14, 2020

   ContributorAuthor

   More actions

   Yeah, this is why I would like to use Bearer header token, so that a user agent can register a new client.
3. rohe commented on May 14, 2020

   

   rohe

   on May 14, 2020

   Contributor

   More actions

   What kind of token and what does it contain if anything ?
4. angelakis commented on May 14, 2020

   

   angelakis

   on May 14, 2020

   ContributorAuthor

   More actions

   Just an ordinary access token issued through another client.
5. rohe commented on May 14, 2020

   

   rohe

   on May 14, 2020

   Last edited by rohe

   Contributor

   More actions

   What ? Do I get this right ?
   You plan to use an access token assigned to another client (let's call him A) to be used as an authentication token by a new, un-registered client (B).
   If B is to use it, it MUST be in the aud list (if it's a JWT token). But it can't because it doesn't have a name yet ?!
6. angelakis commented on May 21, 2020

   

   angelakis

   on May 21, 2020

   ContributorAuthor

   More actions

   So let's say we have a client A and user X. We are the OP, we trust user X and we would like to allow her to register a new client B.

   So user X goes to client A and authenticates with us. She then (through A, who supports this functionality) registers the new client B. So A issued a POST to us, using Bearer ******** as an authorization header, where ******** the access token for X.

   I can already achieve this by writing a custom authentication class:

   class CustomAuth(ClientAuthnMethod):
       tag = 'customauth'
   
       def is_usable(self, request=None, authorization_info=None):
           return(
               authorization_info is not None
               and authorization_info.startswith("Bearer ")
           )
   
       def verify(self, authorization_info, **kwargs):
           import pdb;pdb.set_trace()
           token = authorization_info[len("Bearer "):]
           _sdb = self.endpoint_context.sdb
   
           if not _sdb.is_token_valid(token):
               raise AuthnFailure()
   
           session = _sdb.read(token)
           if (session["authn_event"]["valid_until"] <= time_sans_frac()
               and "offline_access" not in session["authn_req"]["scope"]
           ):
               raise AuthnFailure()
   
           # info = collect_user_info(self.endpoint_context, session)
   
           return {"client_id": session['client_id']}
   

   To make the use case clearer we could extend this to use the user info attributes and check if a user's specific claim/attribute has the value we want, so only then we allow the registration of a new client.
7. angelakis commented on May 21, 2020

   

   angelakis

   on May 21, 2020

   ContributorAuthor

   More actions

   That's what I have in mind at least, I hope it makes (a bit) sense.
8. rohe commented on Sep 7, 2020

   

   rohe

   on Sep 7, 2020

   Contributor

   More actions

   I don't think we reached an agreement on this issue.
   First as you said you could implement this functionality by writing a custom authentication class and obviously you have a use case.
   The question then is whether this is something we want in the core distribution or not ?
9. peppelinux commented on Nov 28, 2020

   

   peppelinux

   on Nov 28, 2020

   Last edited by peppelinux

   Member

   More actions

   @angelakis please let us know if you can continue this thread, feel free to close It, I'm not aware if It Is something that would drive us to a conclusion. Share your thought if possible