Add an example of validating a bearer token

[kaol]

It wasn't obvious to me how to use a JWKSet to verify an access token, I think it'd be worth it to have an example in openid-connect about it as well.

I hope you don't mind that I changed the type of success a bit too, I think the example is clearer if the pattern match for Nothings was removed from it.

[pjones]

@kaol Can you please point me to the location within the OpenID Connect specification that covers this "protected" response from an OpenID provider. Thank you.

[kaol]

I don't think OpenID Connect spec has all that much about bearer token usage by itself. My understanding is that they're more of a generic OAuth 2.0 thing. https://datatracker.ietf.org/doc/html/rfc9068 covers it and I think the new end point to the example would be valid and common OAuth 2.0 use case.

Or is this just more of a question about naming? I'm not sure where I'd find key words Index/Login/Success/Failed in there either, if that's a criterion. I though you were just using descriptive, not spec based naming.

If you have a better idea about how to demonstrate a non-trivial use of providerKeys I could look into making one.

[pjones]

I looked over RFC 9068 and I don't see anything about a "protected" endpoint.

My concerns are:

1. I don't understand what this endpoint is for. How is it different than the success endpoint? If this is strictly for OAuth maybe it belongs in another library.
2. The protected handler is doing a lot of string manipulation. If this protected endpoint is something we want to support I think we should hide away the details in the library and provide a function to do the dirty work.

In the end, I'm worried that adding this will lead to more confusion than it's worth. But my ignorance w.r.t. what the protected endpoint is doing or what it's for is getting in the way of me understanding the usefulness of this change.

[kaol]

As they were originally conceived, bearer tokens were just random strings and keeping track of them was not much unlike using a session cookie. That requires the server to keep state.

JWT bearer tokens can be used to make stateless servers. It ties to OpenID Connect because that's how you get them and the provider's key can be used to verify them, using nothing but it and a time stamp to check expiry. Alternatively, if the application requires more control over whether a given token is still valid due to logging out it can instead of just checking a token against a public key contact the provider and it'll know to tell the application if the user has logged out. Again using data from OpenID Connect.

Whether to do either is up to the application. And neither of these are really in the scope of OpenID Connect, it's concern is just with authentication and this is how you do authorization.

Instead of calling it "protected", it could be something like "list articles" or "edit articles" and doing either requires authorization.

And regarding the string manipulation with the header field, the "proper" way of doing it with Servant which you are doing would be, let's say, involved: https://docs.servant.dev/en/stable/tutorial/Authentication.html I think what I did is still easier to follow if the aim is to focus on the parts that just concern OpenID Connect.

It's my opinion that JWT bearer token use is a good example of how to use the provider's public key and it's how you'd make use of a provider and openid-connect library. But if none of that concerns you then I guess you can close this.

[pjones]

@kaol Thank you for taking the time to explain that to me.

If I understand correctly, I think there is value in having an example of how to use these JWT bearer tokens. That said, I think it should be a separate example where you demonstrate various resources that are protected via authorization claims.

Does that make sense?

[kaol]

Yes, it's clearer if it's well separated from the usual login path. I can add to this same PR that and I'll document what and why it's doing what it is. I already wrote most of that by now.

[pjones]

Fantastic. Thank you.