Hello,
I am developing a REST API and trying to follow the OAuth 2.0 protocol
for authentication, and have a few questions for you good folks.
The use case I'm interested in is native applications (such as linux
command-line programs) that are unable or unwilling to involve a
user-agent. In this case, it seems redirection-based flows
("Authorization Code" and "Implicit Grant Types") are out! That
leaves "Client Credentials" and "Resource Owner Credentials".
"Client Credentials" do not seem appropriate because the client may be
installed on multiple machines and used by different resource owners.
"Resource Owner Credentials" COULD work, but I'd rather not require
the resource owner to reveal their username and password.
One solution, which seems reasonable to me, would be to extend OAuth2
to include another grant type called "Manual Authorization Code".
Using a web browser, the resource owner would login & authenticate
with the authorization server (using session log-on, etc). From there
they could enter an Application ID and press a button "Generate Manual
Authorization Code". The resource owner would then type this Manual
Authorization Code into the client, and the client could exchange it
for an Access Token.
But before I go down this route -- writing an extension, etc.. -- I
wanted the WG's feedback. It seems there are a few different ways to
handle this use case and was curious which you think best matches the
intentions of the OAuth2 spec.
POSSIBLE APPROACHES:
(1) "Manual Authorization Code" extension.
See description above.
(2) "Client Credentials" with each resource owner registering a separate client.
We could achieve a similar effect to (1) by using "Client
Credentials". Say the client is a command-line program
"example-client-cli", which a large number of resource owners have
downloaded and installed. Each resource owner would register the
client with the authorization server and configure their local install
by telling it the client_id and client_secret.
(3) Something else entirely?
QUESTIONS FOR YOUR:
(Q1) Has the WG thought about this particular use case ("CLI clients")
and do you have a recommended authorization approach.
(Q2) Do Manual Authorization Codes make sense? Would anyone else find
it useful to have - if I were to write up an extension document for
it?
Thanks in advanced for you help!
Cheers,
Greg Prisament
Software Architect
PowerCloud Systems
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
