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

From: Dick Hardt <[email-masked]>
Date: Fri, 1 Oct 2021 10:06:49 -0700

If it were me, I would be looking at one of two options.

If you have  a number of resource servers, then I would have one AS that
would manage authentication and authorization of the client. This enables
separation of concerns of client authn and authz from the RS, and puts
client blacklisting in one place. The client sends its request to the AS
signed by its key, and the AS returns an access token to be used against
the RS. You could layer on DPoP if needed.

If there is really only one service, then there is little value in an AS. I
would have the client post a JWT that has the request payload in it, or a
detached signature if it is a large payload. Personally, I like sending the
request as a JWT as it allows services further down the processing pipeline
to independently verify the request from the client.

This assumes sufficient computing power on the IoT device, and reasonably
low call volume.
ᐧ

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

> 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]> wrote:
>
> 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: David Waite <[email-masked]>
Date: Fri, 1 Oct 2021 15:03:46 -0600

> On Oct 1, 2021, at 11:06 AM, Dick Hardt <[email-masked]> wrote:
<snip>
> If there is really only one service, then there is little value in an AS. I would have the client post a JWT that has the request payload in it, or a detached signature if it is a large payload. Personally, I like sending the request as a JWT as it allows services further down the processing pipeline to independently verify the request from the client.
> 
> This assumes sufficient computing power on the IoT device, and reasonably low call volume.
> ᐧ

One interpretation of the purpose in the AS is to create tokens based on its authorization decisions, while direct submission of client-authored JWTs would be more in line with having the RS make those decisions directly.

Even if they were hosted on the same hardware, I’d still push to use an AS-role component in order to optimize the decision making process and to not have to refactor (or risk duplication) of that logic later.

-DW

---

From: <[email-masked]>
Date: Mon, 4 Oct 2021 02:26:43 +0000

Thanks Dick,

Our use case is basically the option 2. There is only one RS. So, to simplify
the architecture, we want to omit the round-trip of getting an access token from
AS.

I agree with your idea of using JWTs to convey client's signature. So my
original question was if there was a standardized profile of a JWT for that
purpose. From the responses to this thread so far, I think the answer is no.

Thanks for comment, David,

Yeah, maybe it's wise to have AS anyway for better extensibility.

Toshio Ito

From: David Waite <[email-masked]>
Sent: Saturday, October 2, 2021 6:04 AM
To: Dick Hardt <[email-masked]>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] self-issued access tokens

On Oct 1, 2021, at 11:06 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
<snip>

[イメージは差出人によって削除されました。]ᐧ

-DW

---

From: Warren Parad <[email-masked]>
Date: Mon, 4 Oct 2021 11:24:03 +0200

fwiw we are currently doing this in some flavor, and there are two things
that have come up:

   - Standardize place to read client public keys from (JWKs)--Currently
   these are uploaded to the AS for storage for a particular client. This
   helps to avoid needing every client to host the public key. Obviously
   putting the public key in the jwt is rife with vulnerabilities.
   - Impossible to prevent client impersonation attacks by default with
   crypto/jwt verification libraries as the client can create tokens that
   specify a different sub then the clients. Because this extra restriction
   exists which is non-standard, verification can't be automatically handled
   by a library that doesn't understand this restriction. Which means that the
   only place which can verify that the sub is actually valid for the client
   is also the AS. (Specifically for us we make this easier by authorizing
   token that fetch AS resource data, including JWKs)

It would be great to have a standard around the second one, but I honestly
don't see how, since the client can always lie, there would have to be a
signature format that stores the *kid/clientId* identification information
in a way that is tamper proof or still the trusted third party in this case
the AS. We tend to call this reverse oauth. A small consolation would be a
standard adding an attribute to the JWK and the JWT signally the
requirement that the sub has to match some other property, but I also don't
see this happening.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Mon, Oct 4, 2021 at 4:28 AM <[email-masked]> wrote:

> *From:* David Waite <[email-masked]>
> *Sent:* Saturday, October 2, 2021 6:04 AM
> *To:* Dick Hardt <[email-masked]>
> *Cc:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]>;
> [email-masked]
> If there is really only one service, then there is little value in an AS.
> I would have the client post a JWT that has the request payload in it, or a
> One interpretation of the purpose in the AS is to create tokens based on
> its authorization decisions, while direct submission of client-authored
> JWTs would be more in line with having the RS make those decisions directly.
>
>
>
> Even if they were hosted on the same hardware, I’d still push to use an
> AS-role component in order to optimize the decision making process and to
> not have to refactor (or risk duplication) of that logic later.
>
>
>
> -DW
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Chadwick <[email-masked]>
Date: Mon, 4 Oct 2021 11:28:05 +0100

What we have done in our verifiable
credentials implementation is to define sub as did:jwk:<base64
encoded public key parameters>. (Note this is a non-standard
DID.) Then the JWT is signed with the corresponding private key.
This provides a JWT that is tamperproof and provides POP, but of
course it does not authenticate the sender as anyone can produce
such a JWT. However, in the case of VCs, the claim is a verifiable
presentation signed by the sender, contain verifiable credentials
issued by a trusted issuer that tells the recipient who the sender
is, so this solves the authentication problem.

I don't know if you could adapt the
above to your requirements, but it would be nice to find an
alternative sub encoding that contains the public key parameters,
and is a URI, without it being a DID.

Kind regards

David

On 04/10/2021 10:24, Warren Parad
wrote:

fwiw we are currently doing this in some flavor,
and there are two things that have come up:

Standardize place to read client public keys from
(JWKs)--Currently these are uploaded to the AS for storage
for a particular client. This helps to avoid needing every
client to host the public key. Obviously putting the
public key in the jwt is rife with vulnerabilities.

Impossible to prevent client impersonation attacks by
default with crypto/jwt verification libraries as the
client can create tokens that specify a different sub then
the clients. Because this extra restriction exists which
is non-standard, verification can't be automatically
handled by a library that doesn't understand this
restriction. Which means that the only place which can
verify that the sub is actually valid for the client is
also the AS. (Specifically for us we make this easier by
authorizing token that fetch AS resource data, including
JWKs)

It would be great to have a standard around the second one,
but I honestly don't see how, since the client can always lie,
there would have to be a signature format that stores the kid/clientId
identification information in a way that is tamper proof or
still the trusted third party in this case the AS. We tend to
call this reverse oauth. A small consolation would be a
standard adding an attribute to the JWK and the JWT signally
the requirement that the sub has to match some other property,
but I also don't see this happening.

- Warren

Warren Parad

Founder, CTO

Secure your user data
with IAM authorization as a service. Implement Authress.

On Mon, Oct 4, 2021 at 4:28 AM
<[email-masked]>
wrote:

Thanks
Dick,

Our
use case is basically the option 2. There is only one
RS. So, to simplify

the
architecture, we want to omit the round-trip of
getting an access token from

AS.

I
agree with your idea of using JWTs to convey client's
signature. So my

original
question was if there was a standardized profile of a
JWT for that

purpose.
From the responses to this thread so far, I think the
answer is no.

Thanks
for comment, David,

Yeah,
maybe it's wise to have AS anyway for better
extensibility.

Toshio
Ito

Cc: ito toshio(伊藤
俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ)
<[email-masked]>;
[email-masked]

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

On Oct 1,
2021, at 11:06 AM, Dick Hardt <[email-masked]>
wrote:

<snip>

If there
is really only one service, then there is
little value in an AS. I would have the
client post a JWT that has the request
payload in it, or a detached signature if it
is a large payload. Personally, I like
sending the request as a JWT as it allows
services further down the processing
pipeline to independently verify the request
from the client.

This
assumes sufficient computing power on the
IoT device, and reasonably low call volume.

ᐧ

One
interpretation of the purpose in the AS is to
create tokens based on its authorization
decisions, while direct submission of
client-authored JWTs would be more in line with
having the RS make those decisions directly.

Even if they
were hosted on the same hardware, I’d still push
to use an AS-role component in order to optimize
the decision making process and to not have to
refactor (or risk duplication) of that logic
later.

-DW

OAuth mailing list

[email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 4 Oct 2021 08:43:32 -0700

Toshio, unless your system needs to interoperate with third party systems,
I don't see the value in a standardized JWT. The JWT standard provides a
standard token format. What you put in the payload is application specific.

You can do a separation of concerns behind your API endpoint for validating
the JWT. If it were me, I would not set up an AS. You won't have to set up
the endpoint and the extra call in your client.

ᐧ

---

From: <[email-masked]>
Date: Mon, 4 Oct 2021 23:56:26 +0000

Thanks Dick,

I understand. If the protocol flow is closed within our system, there is little
value in standardization.

Maybe what I really need is not exactly a standard about self-issued access
tokens. Rather, I look for recommendations, best practice documents or
implementations about it. If it were such things, we could just reuse that and
apply to our system.

Toshio Ito

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

Toshio, unless your system needs to interoperate with third party systems, I don't see the value in a standardized JWT. The JWT standard provides a standard token format. What you put in the payload is application specific.

You can do a separation of concerns behind your API endpoint for validating the JWT. If it were me, I would not set up an AS. You won't have to set up the endpoint and the extra call in your client.

On Sun, Oct 3, 2021 at 7:26 PM <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Dick,

Toshio Ito

From: David Waite <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, October 2, 2021 6:04 AM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] self-issued access tokens

-DW

[イメージは差出人によって削除されました。]ᐧ