[OCM] Re: Token exchange is missing third party token validation

[Micke Nordin <[e-mail]>]

You can see my reply to Matthias for details, but let me state it more 
succinct here:

The third party authentication is something all webapp integrations will 
need to figure out, either by token introspection or JWT. If we 
prescribe it, all integrations of third party software (JupyterHub, 
Collabora, and friends) will automatically work with all OCM servers, 
rather than having to be integrated one by one, in slightly different 
ways. It is very little code, that you were going to write anyway, and 
it makes interoperability easier, not harder.


/Micke

On 5/7/26 3:25 PM, Giuseppe Lo Presti wrote:
> Now I see where you want to go: we don't need to _prescribe_ JWT, we 
> may still _recommend_ it in particular in the context of third-party 
> servers. But yes, it's an implementation detail after all.
>
> Giuseppe
>
>
> On 07.05.2026 15:16, Matthias Kraus wrote:
>> Hi,
>>
>> what I'm saying is, leave it open to the SendingServer implementation 
>> if it uses JWTs or something else. It should not affect the 
>> ReceivingServer. So I wouldn't specify it's contents, it's an 
>> implementation detail.
>>
>> I still agree JWTs are a good idea there, I just wouldn't force all 
>> implementations to use them, if it's not necessary for compatibility.
>>
>> Best
>> Matthias
>>
>> Am 7. Mai 2026 06:58:48 GMT-06:00 schrieb Giuseppe Lo Presti 
>> <Giuseppe.LoPresti=[e-mail]>:
>>> Hi there,
>>>
>>> Thanks Micke for the proposal, as commented over chat I'd go for the 
>>> JWT route.
>>>
>>> And I definitely agree with Matthias, similarly to user or share 
>>> identifiers, the receiving end should make no assumptions whatsoever 
>>> on their format - as only the sending server would consume it 
>>> afterwards.
>>>
>>> Cheers,
>>> Giuseppe
>>>
>>>
>>> On 07.05.2026 14:47, Matthias Kraus wrote:
>>>> Hi,
>>>>
>>>> I would make sure the token is opaque to Receiving Servers. What it 
>>>> contains is up to the SendingServer Implementation, so the 
>>>> SendingServer is free to use anything, e.g. a JWT, to allow its 
>>>> Services to authenticate it.
>>>>
>>>> Then it's a implementation detail when the webapp service is 
>>>> configured to send tokens it gets to some (oidc?) authentication 
>>>> service or to validate the JWT.
>>>>
>>>> That way we minimize complexity across Implementations which would 
>>>> harm compatibility.
>>>>
>>>> I haven't implemented the token flow so far, so tell me if I've 
>>>> missed something.
>>>>
>>>> Best,
>>>> Matthias
>>>>
>>>>
>>>>
>>>> Am 6. Mai 2026 01:20:34 GMT-06:00 schrieb Micke Nordin 
>>>> <kano=[e-mail]>:
>>>>
>>>>      In the so called "code flow" we specify a /token endpoint where
>>>>      you can exchange a sharedSecret for an opaque access token in the
>>>>      vain of OAUTH 2.
>>>>
>>>>      Now that we are starting to work on webapp sharing, I notice that
>>>>      we are missing the ability for third parties to validate an 
>>>> issued
>>>>      access token.
>>>>
>>>>      User X on Server A shares a webapp with User Y on Server B. 
>>>> Server
>>>>      B exchanges the sharedSecret for an access_token at Server A's
>>>>      token endpoint and posts this access_token into the webapp 
>>>> servers
>>>>      iframe. The webapp server of Server A is in this case not the OCM
>>>>      server itself, but rather a third party such as Jupyterhub or a
>>>>      wopi server. Now the webapp server needs to validate the
>>>>      access_token with Server A, but now with the current spec, we are
>>>>      stuck.
>>>>
>>>>      There are two ways to solve this:
>>>>
>>>>      1. We introduce a token introspection endpoint:
>>>> https://www.oauth.com/oauth2-servers/token-introspection-endpoint/
>>>>
>>>>      2. We use JWT profile for OAUTH access tokens
>>>>      https://datatracker.ietf.org/doc/html/rfc9068
>>>>
>>>>      Both of these have some drawbacks:
>>>>
>>>>      1. The introspection endpoint needs either be autheticated with
>>>>      basic auth, or hidden behind access lists.
>>>>
>>>>      2. If we go the JWT route, the token is no longer opaque.
>>>>
>>>>      To me it seems like using JWTs with content we can examine and
>>>>      verify signatures on are the simplest to implement and makes most
>>>>      sense to me. We already require servers that use the code flow to
>>>>      sign requests using http-sig so the key material we need is
>>>>      already there, so we only need to change the spec to specify the
>>>>      structure of the JWT access_token.
>>>>
>>>>      Whats do you think?
>>>>
>>>>      All the best,
>>>>      Micke
>>>>
>>>>
>>>> _______________________________________________
>>>> OCM mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> _______________________________________________
>>> OCM mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> OCM mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OCM mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]