Epic: Client Authorization Model about spring-authorization-server

[Captain-P-Goldfish]

I'd try myself on this one

[Captain-P-Goldfish]

@jgrandja : My mind crossed a question while thinking of some details on this ticket and I'd like to here your opinion to that.

If a client receives authorization for several user resources in a single access token that are quite different in representation and type, would you still use a single resource-endpoint to retrieve all of these resources in one go with an explanation on a documentation on how to parse these resources or would you provide several endpoints?

If your preference is to create several endpoints:
How about if we provide information of the endpoints that can be accessed with the access token within the access token itself by using a JWT representation as access token?

I know this is still a thought for the future but I think its worth to keep in mind

[jgrandja]

@Captain-P-Goldfish

I'd try myself on this one

Issues with the Epic: prefix are intended to group one or more other issues that compromise the bigger feature (epic). The 2 issues #40 and #43 are already taken. Please take a look at Feature Planning so you can see what is being working on currently and the feature roadmap (using ZenHub).

The features I planned out last week are all taken. But you're the first one on my list for the next set of issues, which I'll plan some time this week. Stay tuned.

As far as your other comment, I'm not sure I understood. Maybe log a new issue so we can discuss there. FYI, the JWT epic and associated issues is coming up soon.

[dfcoffin]

@Captain-P-Goldfish @jgrandja I believe #52 addresses your concern and implements OAuth 2.0 Token Introspection [RFC 7662]