Ancestors

Written by Erin 💽✨ on 2025-01-22 at 11:59

Early drafts of OAuth2 did what?!

Authorization servers respond to client requests by including a set

of response parameters in the entity body of the HTTP response. The

response uses one of three formats based on the format requested by

the client (using the "format" request parameter or the HTTP "Accept"

header field):

o The "application/json" media type as defined by [RFC4627]. The

  parameters are serialized into a JSON structure by adding each

  parameter at the highest structure level.  Parameter names and

  string values are included as JSON strings.  Numerical values are

  included as JSON numbers.

  For example:

 {

   "access_token":"SlAV32hkKG",

   "expires_in":3600,

   "refresh_token":"8xLOxBtZp8"

 }

o The "application/xml" media type as defined by [RFC3023]. The

  parameters are serialized into an XML structure by adding each

  parameter as a child element of the root "<OAuth>" element. [[ Add

  namespace ]]

  For example:

 <?xml version='1.0' encoding="utf-8"?>

 <OAuth>

   <access_token>SlAV32hkKG</access_token>

   <expires_in>3600</expires_in>

   <refresh_token>8xLOxBtZp8</refresh_token>

 </OAuth>

o The "application/x-www-form-urlencoded" media type as defined by

  [W3C.REC-html401-19991224].

  For example (line breaks are for display purposes only):

 access_token=SlAV32hkKG&expires_in=3600&

 refresh_token=8xLOxBtZp8

The authorization server MUST include the HTTP "Cache-Control"

response header field with a value of "no-store" in any response

containing tokens, secrets, or other sensitive information.

link

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Toot

Written by Erin 💽✨ on 2025-01-22 at 12:01

(I was looking at some OAuth 2 client code and found a fossil of this in the form of still supporting parsing responses in x-www-form-urlencoded format and I was like “what. why. did someone implement the spec wrong?!” and it looks like the answer is “no, the spec was just briefly bonkers”)

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Descendants

Written by Erin 💽✨ on 2025-01-22 at 12:02

(“did someone implement the spec wrong?” yes. of course they did. its oauth 2. its more vibes than a spec to begin with and yet people manage to find new and creative ways to violate the bits that are nailed down all the time)

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Emelia 👸🏻 on 2025-01-22 at 12:08

@erincandescent looks at us all making client_id no longer an opaque string 😅😅

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Erin 💽✨ on 2025-01-22 at 12:12

@thisismissem I was about to say “I thought I saw a draft from @aaronpk about this” and then I looked at the coauthors 🙈

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Erin 💽✨ on 2025-01-22 at 12:18

@thisismissem @aaronpk I am a bit concerned that we seem to have multiple specs piling up (yours, OpenID Federation, others?) which specify “If you receive a client ID which is a https URL, go and fetch this document“ with different values for this document and am concerned we’re gonna end up in a world where ASes are having to probe multiple options (and then what happens if a client supports multiple options? which do you pick? how do you prioritise?)

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Emelia 👸🏻 on 2025-01-22 at 12:22

@erincandescent @aaronpk there was a interim meeting about it. Basically adding something like client_type is the way to go

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Erin 💽✨ on 2025-01-22 at 12:26

@thisismissem @aaronpk hmm ok. I worry about anything that’s an additional field because client IDs end up in JWT/CWT/Introspection sub/aud/client_id claims

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Emelia 👸🏻 on 2025-01-22 at 12:29

@erincandescent @aaronpk yeah, but Client IDs in those are an opaque string

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Erin 💽✨ on 2025-01-22 at 12:35

@thisismissem @aaronpk per spec they need to match the client_id as used at the authorization/token endpoints, so the typing needs to be encoded in the ID else you end up with the possibility of two different clients with the same ID

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Emelia 👸🏻 on 2025-01-22 at 12:43

@erincandescent @aaronpk I'd be inclined to suggest that no, since the documents aren't requested with any specific headers there's no negotiation that could happen on same URL, and in fact I might add a MUST NOT on client_id metadata documents to only serve that file not attempt negotiation

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Erin 💽✨ on 2025-01-22 at 15:12

@thisismissem @aaronpk for OID Fed you don't request that address directly, you request a .well-known subdir...

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Erin 💽✨ on 2025-01-22 at 15:33

@thisismissem @aaronpk anyway I wouldn't want to assume someone will never need to do both

I can imagine e.g. a university AS might be part of an OpenID Federation and also function as the OAuth 2 AS for a fediverse server

=> More informations about this toot | More toots from erincandescent@erincandescent.net

Written by Emelia 👸🏻 on 2025-01-22 at 17:04

@erincandescent @aaronpk I think those would be different AS's since Mastodon is an AS, and doesn't delegate that

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Emelia 👸🏻 on 2025-01-22 at 12:29

@erincandescent @aaronpk in practice though, you'd probably never implement an AS supporting both OpenID Federation and Client ID Metadata Documents as they've significantly different trust models and use cases

But there's two others that may be used together, I can't remember which off top of head.

This was an early proposed solution: https://drafts.aaronpk.com/oauth-client-id-scheme/draft-parecki-oauth-client-id-scheme.html

=> More informations about this toot | More toots from thisismissem@hachyderm.io

Written by Scarlet ❤️‍🔥 on 2025-01-22 at 12:42

@erincandescent >“did someone implement the spec wrong?” yes

every single time 😭

=> More informations about this toot | More toots from scarlet@chaos.social