[Koha-bugs] [Bug 30988] Add generic OpenIDConnect client implementation

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30988

--- Comment #44 from Shi Yao Wang <shi-yao.wang at inLibro.com> ---
(In reply to Martin Renvoize from comment #42)
> This is looking good.. a few comments of where I'd love to see it headed and
> one that is unfortunately a QA fail at the moment.
> 
> QA Fail
> * We're missing Unit Tests for the new module you introduce, I'm afraid
> that's a hard fail for now.  It also looks like you have a note to do
> validation here which is missing... little confused as it looks like you are
> passing in a json structure rather than the token string.. so I'd have
> expected that to already be verified?  We could perhaps just use an existing
> library for this Mojo::JWT for instance?

Sorry, I am not really knowledgeable on the subject of token validation. For
the note, I put it there because I saw this note in the file
opac/svc/auth/googleopenidconnect that I copied to opac/svc/auth/openidconnect
when I started:
># Normally we'd have to validate the token - but google says not to worry here (Avoids another library!)
># See https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo for rationale

So I rewrote the note in the same spot just to give a heads up since I am not
sure if it is needed and I couldn't figure out how to do it if it is needed. I
looked into it a little and I think it has something to do with validating the
token signature involving kid attribute (key id) and jwks_uri of the discovery
document?

> little confused as it looks like you are
> passing in a json structure rather than the token string.. so I'd have
> expected that to already be verified?

The json passed in looks like this:
>{
>    'access_token' => '(encoded stuff)'
>    'id_token' => '(encoded stuff)'
>    'scope' => 'openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email'
>    'expires_in' => 3598
>    'token_type' => 'Bearer'
>}
Then 'id_token' is split (into 3 parts) by '.' and the middle part is decoded
into another json that contains the claims. Hope this helps comprehension.

-- 
You are receiving this mail because:
You are watching all bug changes.