Epic: Client Authorization Model

[jgrandja]

This epic will track the progress of the following feature:

Provide a domain model for a client registration and authorization-related data associated between a client and a resource owner.

This epic is divided into multiple issues, in order to support parallel work streams.

#40 Implement Client Registration Model / Repository
#43 Implement Authorization Model / Service

See the ZenHub project board.

[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]