Transport method other than HTTP about osin

[liggitt]

Not sure what you're envisioning. The OAuth spec dictates http as the transport mechanism for both the authorization and token requests.

[JesseFarebro]

Yes, I know it does. I can attempt to describe what I was thinking and why I would want such a feature.

Let's assume I have a bunch of services that communicate through RPC (thrift, gRPC, etc.). I do have an HTTP front end but maybe I would want a service that my HTTP front end would delegate the authentication/authorization requests to. This way say I get a request I can chain these service calls by verifying an access token, checking scopes then hitting a database if it has the specified scope.

Yes, I could very well do all of this on my web frontend and just do these checks before sending an RPC request to another service but in my opinion it just seemed more decoupled this way (my proposal).

Now I do realize the benefit of the majority (no breaking API changes) over my small use case here, but I was just wondering if you'd be open to such a change. I always believed decoupling things like this would be a better design philosophy to begin with.

[liggitt]

Still not seeing the integration. The part of OAuth osin implements is oriented toward obtaining a token, not using it against an API. Whatever storage mechanism you implement that can retrieve token details for a given token could be used by an authn/authz layer for any arbitrary API (http, rest, RPC, etc), but usage of an access token to auth to an API doesn't have anything to do with how the token was obtained.

[JesseFarebro]

Absolutely, I understand that. I guess the pursuit was just to decouple things more for myself. I would of liked to have the token generation, authorization etc. all in one easy place but it's not the end of the world.

Thank you!