You can fashion such thing using the dict protocol, we have no plans to include 
that kind of tooling with community dovecot at this moment.

Aki

> On 11/08/2021 10:06 Tomas Habarta <[email protected]> wrote:
> 
>  
> Yep, that was the point, RFC states typ header as optional so I was looking 
> for some workaround as the implementation did not put it in the tokens. 
> Fortunately, I had a great luck as developers were so kind and added it with 
> next minor release -- so this is sorted and local validation works great.
> 
> Next question is related to the key management -- as the key used for 
> validation is publicly available at JWK endpoint, is there any plan to 
> enhance dovecot's functionality so that keys can be retrieved from such 
> well-known endpoint? For the meantime, it is relatively easy task to be 
> scripted, but don't want to spend much time reinventing the wheel since I 
> have no other mechanism to prevent outage in case of 
> planned/unplanned/emergency signing key change...
> 
> 
> Thanks!
> Tomas
> 
> On Mon, Jun 28, 2021 at 08:43:09AM +0300, Aki Tuomi wrote:
> > 
> > > On 24/06/2021 09:19 Tomas Habarta <[email protected]> wrote:
> > > 
> > >  
> > > Hello,
> > > 
> > > I have a working setup with Roundcube using OAuth2 -- introspection works 
> > > without any problem, unfortunately local validation does not as tokens 
> > > are missing "typ" header (seems that one is indeed optional per RFC7519 
> > > and therefore not present in the implementation in place).
> > > Is there any parameter to assert the token type or any other workaround 
> > > to make local validation work as it currently fails with: oauth2 failed: 
> > > Local validation failed: Cannot find 'typ' field.
> > > 
> > > dovecot v2.3.15
> > > Roundcube 1.5beta
> > > CentOS 8
> > > 
> > > 
> > > Thanks, regards
> > > Tomas
> > 
> > Hi!
> > 
> > The current dovecot oauth2 code requires that your tokens come with typ:jwt 
> > header. See https://datatracker.ietf.org/doc/html/rfc7519#section-5.1
> > 
> > Aki

Reply via email to