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.

ᐧ

On Tue, Sep 28, 2021 at 6:55 PM <toshio9.ito@toshiba.co.jp> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>