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

[[e-mail]]

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 <[e-mail]>
Sent: Thursday, September 30, 2021 12:27 AM
To: Vittorio Bertocci <Vittorio=[e-mail]>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[e-mail]>; IETF oauth WG <[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
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



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