On 11/19/2014 7:01 AM, Stian Thorgersen wrote:
First thing, is this script a CLI that a user invokes, a background
process that runs on behalf of the user, or a server?
If it's a CLI I'd say it should ask user for username/password and use direct
grant to obtain token. The refresh token could be saved in a tmp file, or in users home
directory. Next time the CLI wants to invoke this it'll need to make sure the token
isn't expired, if it is refresh before invoking the service.
If it's a background process you'll need a setup script that asks users for
username/password or as you suggest use a browser to login. After that it's the same
as above. One exception though is that in this case you probably want an offline token,
which is something we don't support yet. Basically an offline token would be a token
that's not associated with a specific user session, which would have a longer
(possibly unlimited) lifetime. The user would also need to be able to view and revoke
these tokens through the account management.
If it's a server it should use a certificate to authenticate the server itself. Also,
it should use a "service account" rather than a regular user account. Again,
this is something we don't have atm. We only have regular user accounts and
passwords.
We used to have a "service account" all applications and oauth clients
were users :(
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com