i'm working on a project where we are trying to implement an oauth(2) provider that can be used for sign-on.
for example, a tonr-ish client might have a button labeled 'sign on using your sparklr-ish account',
and when you click it, it does the oauth dance:
(a) prompts you to sign on to sparklr-ish
(b) prompts you to grant access to sparklr-ish resources
(c) gets an auth code and exchanges it for an access token
(d) uses that access token to get a 'user profile' resource with some basic info (first name, last name, username), this basic premise is captured by spring-social
so far, so good.
for this sign-on-using-oauth-provider pattern, we might logout of tonr-ish (having not made any attempts to persist the access token), come back the next day and click the 'sign on using your sparklr-ish account'.
the desired effect is that:
(e) the user is prompted to sign on to sparklr-ish
(f) the user is not prompted to grant access again since they already did this previously
(g) the client gets an auth code and exchanges it for an access token (i think it should be the same access token that was provided the previous day, just so the provider isn't stacking up a new access token in it's database for each of multiple logon events)
(h) the client gets the 'user profile' resource using the access token and does whatever 'account joining' activities it cares to do in terms of reconciling the tonr-ish login session with the sparklr-ish user-profile.
so my questions are generally:
- has anyone successfully accomplished anything like this with s2-oauth?
- if so, any tips?
- is there anything about s2-oauth that would make implementing this behavior cumbersome?
- any other recommendations or thoughts on the topic?