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.