Subject: [OAUTH-WG] Listing OAuth Access Token Metadata

From: Dhaura Pathirana <[email-masked]>
Date: Fri, 1 Apr 2022 14:54:50 +0530

Hi all,

Currently, I am working on a proof of concept to implement Personal Access
Tokens (PAT) as a OAuth2 custom grant type because of the similarities
between OAuth2 and Personal Access Tokens (PAT).

Since the PATs are created, managed and used by users, there is a
requirement of listing the token metadata such as validity period, creation
date, alias and description (the last two attributes are unique to PATs and
part of the custom grant) in order to be viewed by the users (PAT owner).
The main limitation that I came across using a custom grant is that even
though the PATs have this listing requirement, there aren't any token
metadata listing related information in specifications in OAuth2.

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?

Thank You.

Kind Regards,

Dhaura Pathirana

---

From: David Waite <[email-masked]>
Date: Sun, 3 Apr 2022 00:35:15 -0600

> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana <[email-masked]> 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

---

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 4 Apr 2022 02:55:13 +0900

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-masked]> wrote:

> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Warren Parad <[email-masked]>
Date: Sun, 3 Apr 2022 20:42:52 +0200

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-masked]> 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?
>>
>>

---

From: Dhaura Pathirana <[email-masked]>
Date: Wed, 6 Apr 2022 09:19:44 +0530

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-masked]> 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

---

From: Warren Parad <[email-masked]>
Date: Wed, 6 Apr 2022 10:23:40 +0200

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-masked]>
wrote:

> 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.
>
>>>> 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?
>>>>
>>>>