Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Epic: Client Authorization Model #41

Closed
jgrandja opened this issue Apr 20, 2020 · 4 comments
Closed

Epic: Client Authorization Model #41

jgrandja opened this issue Apr 20, 2020 · 4 comments
Labels
type: enhancement A general enhancement
Milestone
0.0.1

Comments

@jgrandja
Copy link
Collaborator

jgrandja commented Apr 20, 2020 •
edited

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.
@jgrandja jgrandja changed the title Authorization Code Service Epic: Authorization Code Service Apr 20, 2020
@paurav-munshi paurav-munshi mentioned this issue Apr 21, 2020
Closed
@jgrandja jgrandja added the status: on-hold We can't start working on this issue yet label Apr 23, 2020
@jgrandja jgrandja changed the title Epic: Authorization Code Service Epic: Client Authorization Model Apr 24, 2020
@jgrandja jgrandja added this to the 0.0.1 milestone Apr 24, 2020
@jgrandja jgrandja added status: ideal-for-contribution An issue that we actively are looking for someone to help us with type: enhancement A general enhancement and removed status: on-hold We can't start working on this issue yet status: ideal-for-contribution An issue that we actively are looking for someone to help us with labels Apr 24, 2020
@Captain-P-Goldfish
Copy link

I'd try myself on this one

@Captain-P-Goldfish
Copy link

Captain-P-Goldfish commented Apr 27, 2020 •
edited

@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
Copy link
Collaborator Author

@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
Copy link

dfcoffin commented Apr 27, 2020 •
edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: enhancement A general enhancement
Projects
None yet
Milestone
0.0.1
Development

No branches or pull requests
3 participants
@dfcoffin @Captain-P-Goldfish @jgrandja