For the listing of all the user's toke, there isn't a standard for that. Additionally these should still be OAuth flow generated tokens via that third party. OAuth tokens are for clients on behalf of users, your use case directly matches with the expectation of OAuth.
Lastly, if you want to add an alias or anything else to these, you can definitely add some additional methods no your AS, but I would recommend instead labeling these tokens as what they will be used for, i.e. the name and Id of the relevant third party client, and not a custom alias. I think if the best way to get advice in this area would be to stipulate why your business use cases are the way they are. There's pretty straight forward ways to solve what you seem to want using OAuth without anything off spec, if there's a real use case missing that should be improved by rev-ing the spec, it's best to talk about the core problems rather than trying to introduce a new flow which con be rife with issues. - Warren On Wed, Apr 6, 2022, 05:49 Dhaura Pathirana <[email protected]> wrote: > Thank you all for the quick replies and I really appreciate the > suggestions. > > One thing that I want to clarify is that, in this use case, the > requirement is to list all the access tokens (metadata) (that belong to a > single owner) issued for the custom grant but in the introspection > specification only metadata can be listed for a given access token. > > Here, we need PATs rather than a standard OAuth grant type because the > token should be issued to a user (not a client) and the user will use this > token to access certain APIs through another third-party application (which > could be a simple automation script). And also, there are some attributes > like alias and description that should be stored with the PAT as they are > required for token identification purposes (Those attributes are not common > with other standard OAuth grant types). Furthermore, the user should be > able to revoke any of his PATs at any time. > > In the ID token suggestion, it is mentioned to look into OIDC ID token > specification. Does it imply that an ID token should be used as a Personal > Access Token, instead of an OAuth2 access token, or is it proposed to > extract user information? > > Thank You. > Kind Regards, > > Dhaura Pathirana > > On Mon, 4 Apr 2022 at 00:13, Warren Parad <[email protected]> wrote: > >> I'm tempted to say user created PATs are incompatible with OAuth, and >> OAuth already has a solution which avoids the user having to manually >> create these sorts of tokens. Is there a reason OAuth wouldn't be able to >> handle the specific use case. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress <https://authress.io/>. >> >> >> On Sun, Apr 3, 2022 at 7:56 PM Takahiko Kawasaki <[email protected]> >> wrote: >> >>> Dear Dhaura, >>> >>> My recommendation to you (undergraduate? LinkedIn says so) is to >>> investigate the following as the first step. >>> >>> >>> - ID Token (OpenID Connect Core 1.0, Section 2) >>> - UserInfo Endpoint (OpenID Connect Core 1.0, Section 5.3) >>> >>> >>> In general, inventing a new grant type should be the last resort. >>> >>> Best Regards, >>> Takahiko Kawasaki >>> >>> >>> On Sun, Apr 3, 2022 at 3:35 PM David Waite <david= >>> [email protected]> wrote: >>> >>>> >>>> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana <[email protected]> >>>> wrote: >>>> >>>> I would like to know if anyone has seen this (listing token metadata) >>>> as a common use case in OAuth2 and a standard way of doing it had been >>>> proposed before? >>>> >>>> >>>> OAuth Token Introspection (RFC 7662) defines a way to query for active >>>> state and meta-info. >>>> >>>> However, its use is defined only for protected resources, and not the >>>> resource owner or the client the token was issued to. >>>> >>>> -DW >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
