[keycloak-dev] Feedback on Oauth Clients
Marek Posolda
mposolda at redhat.com
Mon Oct 7 06:47:43 EDT 2013
Hi,
Google/Facebook also supports something like caching of scopes, which
were approved by user, so that OAuth grant page is displayed just for
the first time.
For example: When user wants access token from Facebook for the first
time, OAuth grant page is displayed for him with message like
"Application XY wants access to your user_info, email". Once user
confirms it, access token is granted and Facebook knows that this user
already approved scopes "user_info" and "email". Once user want access
token for the second time with same scopes, oauth grant page is not
displayed anymore because Facebook knows that this user already
confirmed "user_info" and "email" scopes. OAuth grant page is displayed
just in case that user wants more scopes, which he didn't approve
previously. And in this case OAuth grant page contains just scopes,
which weren't approved by user. So for example: user send request for
scopes "user_info,email,friends_list" but OAuth grant page will display
just "friends_list" because scopes "user_info,email" were already
approved previously.
All those cached scopes are destroyed in case that:
- User manually removes application from Facebook UI
- User revoke one of access tokens approved for this OAuth client
application
Not sure if this feature is priority for M1 as it seems that it will
require some changes in model and it may be too complex? However I think
that API endpoint for revocation of access tokens will be good. Both
facebook/google supports this. Also it seems that OAuth client should be
able send only scopes, which he needs. Right now, I am seeing that
ServletOAuthClient.redirect doesn't support this. Should I create JIRAs
to track this?
Marek
On 3.10.2013 15:59, Bill Burke wrote:
> I need some feedback on how to handle OAuth Clients. OAuth clients are
> like Applications in that Keycloak is used to log in, but OAuth clients
> are required to be forwarded through the OAuth Grant Page. Users must
> directly grant permission to the OAuth client to access stuff. OAuth
> clients will also not be hooked into Single Logout or the session
> management facilities I hope to incorporate into Keycloak. OAuth
> clients will also not have roles associated with them.
>
> The way google does it is that they require you to login using your
> Google account, then you create applications within their cloud service
> app. Applications get their own unique client-id and password and you
> then assign permissions to this application.
>
> I was thinking we should do something similar for Keycloak.
>
> For our first release, we'll have a specific Admin UI in which you can
> create OAuth clients in much the same way you create applications.
>
> For phase 2, I was thinking that the user account management would be
> expanded to have an option (if allowed by the realm) for creating and
> registering an OAuth client. The user would then have a client-id
> generated for them and they would have to set up credentials for this
> client-id.
More information about the keycloak-dev
mailing list