Provider implementation

[andrewbaxter]

Sorry if I missed something - I did try to dig around, but I don't think there are any specific examples or other issues/discussions related to this.

I'm trying to implement a lightweight oidc provider. AFAIK that usage is within the scope of this crate - the readme has an example for the provider-side well-known endpoint data for instance, providing a struct the provider can return to clients.

I'm trying to parse the query parameters of the initial request to the authenticate endpoint (?redirect_url=abc,state=xyz,... probably with serde_urlencoded) and while there are types that correspond to this data (RequestUrl, or maybe AuthorizationRequest?) they're closed and tightly coupled with the client-side.

Could pure-data types maybe be split out and opened up, or maybe similar provider-side structs be provided? I'm not sure how best to handle it. Though I guess I'd prefer having a bunch of data structs but no help with the request flow than help for part of the request flow but not all the data structs.

[andrewbaxter]

I want to add, I really appreciate the idea of a framework-independent base OIDC library!

[ramosbugs]

Hey @andrewbaxter,

Great points! The provider-side functionality currently offered by this crate is mostly around generating responses (e.g., serializing and signing ID tokens, StandardTokenResponse, etc.).

To parse requests, I think we'd need to introduce new provider-side types. It would feel off to have methods for sending requests (e.g., request/request_async in the case of the token requests) from within provider-side code. For the provider-side AuthorizationRequest, we probably want to deserialize it from a set of pre-parsed query params supplied by whichever server framework the provider is using, which won't include the auth_url unless we do some otherwise-unnecessary work to attempt to reconstruct it.

For the *TokenRequest structs, we probably need a special provider-side type (enum?) since the type of token request won't be known without first parsing it.

I won't have bandwidth to implement these changes in the foreseeable future, but I would be willing to shepherd them through for an interested contributor.

[andrewbaxter]

Oh awesome, thanks for the reply! Same here, but if I have some time I might give it a try.

Yeah, when I pushed a bit farther (for my super minimal provider) the only thing that was really missing was the query string stuff.

In any case, thanks for clarifying and adding direction!