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

[David Chadwick <[e-mail]>]

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

https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA" width="199" height="34">

Warren Parad Founder, CTO

Secure your user data with IAM authorization as a service. Implement https://authress.io/" target="_blank" rel="nofollow">Authress.

On Mon, Oct 4, 2021 at 4:28 AM <[e-mail]> 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

 

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

 

 

On Oct 1, 2021, at 11:06 AM, Dick Hardt <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth" rel="nofollow">https://www.ietf.org/mailman/listinfo/oauth