Subject: [OAUTH-WG] self-issued access tokens

From: <[email-masked]>
Date: Wed, 29 Sep 2021 01:54:15 +0000

Hi OAuth folks,

I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 2014
[*1]. It's an Access Token issued by the Client and sent to the Resource Server.
The token is basically a signed document (e.g. JWT) by the private key of the
Client. The Resource Server verifies the token with the public key, which is
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credentials
Grant flow in simple deployments, where it's not so necessary to separate AS and
RS. In fact, Google supports this type of authentication for some services
[*2][*3]. I'm wondering if there are any other services supporting self-signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
[*3]: https://google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Sep 2021 23:05:48 -0700

If the client is sending a self-signed JWT to the RS, you essentially are
just authenticating directly to the RS. Not really OAuth as the RS has not
delegated authorization authority to the AS.

If the client sends a self-signed JWT (a PAR) to the AS, and gets back an
access token to present to the RS, you get centralized authorization
decisions, a key feature of OAuth.

ᐧ

On Tue, Sep 28, 2021 at 6:55 PM <[email-masked]> wrote:

> [*1]:
> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
> [*2]:
> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 28 Sep 2021 23:13:10 -0700

Hi Toshio,
The scenario you describe is comparable to
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least
in terms of validation logic. Please note that most of the validation
software in common use today expects to work with just a handful of keys,
typically one provider and allowance for rotation, hence it might not be
trivial to repurpose it to perform large table scans in scenarios where you
have many clients and corresponding keys.
Also, Prabath's blog makes a statement that, I believe, overstates what can
be achieved with this approach: he says that this can be a replacement for
TLS mutual authentication, but it isn't really the case as you are still
dealing with a bearer token, which can be replayed after issuance hence
offering less guarantees than mutual TLS.

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 29 Sep 2021 08:26:54 -0700

Vittorio,

I wrote an approach where a client would receive a grant by the
authorization server but issues the token itself. The post can be found
here:
https://oauth.blog/oauthblog.jsp (fancy name: Serverless Token Issuance) I
presented the idea at IIW right before I wrote the post.

I believe that it would work nicely and would avoid the need for an
authorization servers to manage access_token.

Regards,
Sascha

On Tue, 28 Sept 2021 at 23:13, Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

> Also, Prabath's blog makes a statement that, I believe, overstates what
> can be achieved with this approach: he says that this can be a replacement
> for TLS mutual authentication, but it isn't really the case as you are
> still dealing with a bearer token, which can be replayed after issuance
> hence offering less guarantees than mutual TLS.
>
>

---

From: Daniel Fett <[email-masked]>
Date: Wed, 29 Sep 2021 17:42:15 +0200

That very much sounds like a static string as the access token plus DPoP.

-Daniel

-- 
https://danielfett.de

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 29 Sep 2021 21:55:50 -0700

Yeah, Daniel,

I remember we spoke about it. I do think my version is slightly different
as there is no access_token issued by the server.

Regards,
Sascha

On Wed, 29 Sept 2021 at 08:42, Daniel Fett <[email-masked]> wrote:

> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> -- https://danielfett.de
>

---

From: Nikos Fotiou <[email-masked]>
Date: Thu, 30 Sep 2021 09:47:42 +0300

FYI, this is exactly what we are doing in [1] to manage Verifiable Credentials using OAuth2.0. The AS issues a verifiable credential that stays (for long time) in the client. The client uses DPoP to prove ownership of the credential. We just started a new project funded by essif [2] that will further develop this idea and provide implementations.

Best,
Nikos

[1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control for multi-tenant systems using Oauth 2.0 and Verifiable Credentials," Proc. 30th International Conference on Computer Communications and Networks (ICCCN), Athens, Greece, July 2021 (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)
[2]https://essif-lab.eu
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 29 Sep 2021, at 6:42 PM, Daniel Fett <[email-masked]> wrote:
>

---

From: David Waite <[email-masked]>
Date: Thu, 30 Sep 2021 11:44:25 -0600

Are you using DPoP at issuance of the credential and embedding the public key as the means to verify the subject? Are you going so far as using DPoP in lieu of Verifiable Presentation wrappers?

-DW

> On Sep 30, 2021, at 12:47 AM, Nikos Fotiou <[email-masked]> wrote:
>

---

From: "Nikos Fotiou" <[email-masked]>
Date: Fri, 1 Oct 2021 00:40:14 +0300

> Are you using DPoP at issuance of the credential and embedding the public
key as the means to verify the subject? 
Exactly. We are using "client credentials" as grant type. The credential
used as grant is client's public key and we are using DPoP to prove
possession. Then the public key is embedded in the VC (which is encoded as a
JWT). 

 > Are you going so far as using DPoP in lieu of Verifiable Presentation
wrappers?
Yes. Since our VCs are encoded in JWT, they are included in the
Authorization header of HTTP  requests and we are using DPoP to prove
possession. So we do not use Verifiable Presentations at all.

Best,
Nikos

> FYI, this is exactly what we are doing in [1] to manage Verifiable
Credentials using OAuth2.0. The AS issues a verifiable credential that stays
(for long time) in the client. The client uses DPoP to prove ownership of
the credential. We just started a new project funded by essif [2] that will
further develop this idea and provide implementations.
> 
> Best,
> Nikos
> 
> [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access 
> control for multi-tenant systems using Oauth 2.0 and Verifiable 
> Credentials," Proc. 30th International Conference on Computer 
> Communications and Networks (ICCCN), Athens, Greece, July 2021 
> (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.
> pdf)
> [2]https://essif-lab.eu
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile 
> Multimedia Laboratory Athens University of Economics and Business 
> https://mm.aueb.gr

---

From: <[email-masked]>
Date: Fri, 1 Oct 2021 00:58:11 +0000

Thanks Dick,

I agree. The scenario of self-issued access tokens doesn't really follow the
model of OAuth.

So, if we do standardize self-issued access tokens, maybe OAUTH WG is not the
right venue. Maybe HTTPBIS or HTTPAPI WGs?

Toshio Ito

From: Dick Hardt <[email-masked]>
Sent: Wednesday, September 29, 2021 3:06 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] self-issued access tokens

If the client is sending a self-signed JWT to the RS, you essentially are just authenticating directly to the RS. Not really OAuth as the RS has not delegated authorization authority to the AS.

If the client sends a self-signed JWT (a PAR) to the AS, and gets back an access token to present to the RS, you get centralized authorization decisions, a key feature of OAuth.

---

From: <[email-masked]>
Date: Fri, 1 Oct 2021 01:07:00 +0000

Thanks for comment, Vittorio,

Yes, we need to be careful about replay attacks on self-issued access tokens. I
think DPoP Proof provides a good (if not perfect) protection against it because
it contains rich context about the request.

Thanks for the pointer, Sascha,
I'll look at it.

Toshio Ito

From: Sascha Preibisch <[email-masked]>
Sent: Thursday, September 30, 2021 12:27 AM
To: Vittorio Bertocci <Vittorio=[email-masked]>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] self-issued access tokens

Vittorio,

I wrote an approach where a client would receive a grant by the authorization server but issues the token itself. The post can be found here:
https://oauth.blog/oauthblog.jsp (fancy name: Serverless Token Issuance) I presented the idea at IIW right before I wrote the post.

I believe that it would work nicely and would avoid the need for an authorization servers to manage access_token.

Regards,
Sascha

On Tue, 28 Sept 2021 at 23:13, Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>> wrote:
Hi Toshio,
The scenario you describe is comparable to https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least in terms of validation logic. Please note that most of the validation software in common use today expects to work with just a handful of keys, typically one provider and allowance for rotation, hence it might not be trivial to repurpose it to perform large table scans in scenarios where you have many clients and corresponding keys.
Also, Prabath's blog makes a statement that, I believe, overstates what can be achieved with this approach: he says that this can be a replacement for TLS mutual authentication, but it isn't really the case as you are still dealing with a bearer token, which can be replayed after issuance hence offering less guarantees than mutual TLS.

On Tue, Sep 28, 2021 at 6:54 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi OAuth folks,

-------------
Toshio Ito

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: <[email-masked]>
Date: Fri, 1 Oct 2021 01:13:57 +0000

Thanks Nikos,

It sounds interesting to use Verifiable Credentials in this scenario. I'll read
the paper.

Toshio Ito

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Nikos Fotiou
Sent: Thursday, September 30, 2021 3:48 PM
To: Daniel Fett <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] self-issued access tokens

Best,
Nikos

[1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control for multi-tenant systems using Oauth 2.0 and Verifiable Credentials," Proc. 30th International Conference on Computer Communications and Networks (ICCCN), Athens, Greece, July 2021 (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)
[2]https://essif-lab.eu
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr

>> I have a question. Is there (or was there) any standardizing effort 
>> for "self-issued access tokens"?
>> 
>> Self-issued access tokens are mentioned in a blog post by P. 
>> Siriwardena in 2014 [*1]. It's an Access Token issued by the Client and sent to the Resource Server.
>> The token is basically a signed document (e.g. JWT) by the private 
>> key of the Client. The Resource Server verifies the token with the 
>> public key, which is provisioned in the RS in advance.
>> 
>> I think self-issued access tokens are handy replacement for Client 
>> Credentials Grant flow in simple deployments, where it's not so 
>> necessary to separate AS and RS. In fact, Google supports this type 
>> of authentication for some services [*2][*3]. I'm wondering if there 
>> are any other services supporting self-signed access tokens.
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Sep 2021 20:52:49 -0700

Would be useful to understand your use case and what you the goals and
constraints are

On Thu, Sep 30, 2021 at 5:58 PM <[email-masked]> wrote:

> *From:* Dick Hardt <[email-masked]>
> *Sent:* Wednesday, September 29, 2021 3:06 PM
> *To:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] self-issued access tokens
>
>
>

---

From: <[email-masked]>
Date: Fri, 1 Oct 2021 04:45:00 +0000

Thanks Dick,

Our use case is to connect IoT devices to a cloud service. The cloud service has
to authenticate those devices. The devices are not operated by humans. They run
on its own.

We want public key-based authentication for those devices. In that case, mutual
TLS is a popular option (e.g. AWS IoT Core). However, we don't want to use
mutual TLS for several reasons (e.g. it's too coupled with the transport layer).
So, we are seeking a solution that is more in application layer.

Toshio Ito

From: Dick Hardt <[email-masked]>
Sent: Friday, October 1, 2021 12:53 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] self-issued access tokens

Would be useful to understand your use case and what you the goals and constraints are

On Thu, Sep 30, 2021 at 5:58 PM <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Dick,

Toshio Ito

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 29, 2021 3:06 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] self-issued access tokens