[OAUTH-WG] oauth with command line clients

Discussion:

Bill Burke

2017-06-12 03:52:55 UTC

Has anybody done any spec work around doing oauth from command line
interfaces? We're looking for something where the auth server can
generate text-based challenges that are rendered in the console window
that query for simple text input over possibly multiple requests. I'm
not talking about Resource Owner or Client Credentials grant. The
command line client may not know the credential types required for a
successful token request. It would be easy to write a simple protocol,
but I'd rather just do something around any existing internet draft or
rfc that somebody has put some thought into. Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

Aaron Parecki

2017-06-12 03:58:19 UTC

Permalink

I've seen this done a few ways:

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow
which is what you see on browserless devices like the Apple TV logging in
to a cable provider from your phone. A short code is generated and
displayed on the screen, you launch a browser on your phone and enter the
code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the
authorization URL on the command line prompt and instructing the user to
open it in a browser. The redirect URI is a hosted web page that displays
the authorization code and instructs the user to paste it back at the
terminal.
* The command line app can launch an HTTP server on localhost and use that
as the redirect URL for the authorization code flow. This option ends up
being the most seamless since it works like a traditional flow without any
special instructions to the user.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

Post by Bill Burke
Has anybody done any spec work around doing oauth from command line
interfaces? We're looking for something where the auth server can generate
text-based challenges that are rendered in the console window that query
for simple text input over possibly multiple requests. I'm not talking
about Resource Owner or Client Credentials grant. The command line client
may not know the credential types required for a successful token request.
It would be easy to write a simple protocol, but I'd rather just do
something around any existing internet draft or rfc that somebody has put
some thought into. Hope I'm making sense here.
Thanks,
Bill Burke
Red Hat
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Bill Burke

2017-06-12 13:23:21 UTC

Permalink

I've read about these techniques, but, its just not a good user
experience. I'm thinking more of something where the command line
console is the sole user agent and the auth server drives a plain text
based interaction much like an HTTP Server drives interaction with HTML
and the browser.

This isn't anything complex. It should be a simple protocol, but I'd
like to piggy back on existing solutions to build some consensus around
what I think is a common issue with using OAuth. If there isn't anything
going on here in the OAuth group surrounding this, would be willing to
draw up a Draft if there is interest.

https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what
you see on browserless devices like the Apple TV logging in to a cable
provider from your phone. A short code is generated and displayed on
the screen, you launch a browser on your phone and enter the code.
This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the
authorization URL on the command line prompt and instructing the user
to open it in a browser. The redirect URI is a hosted web page that
displays the authorization code and instructs the user to paste it
back at the terminal.
* The command line app can launch an HTTP server on localhost and use
that as the redirect URL for the authorization code flow. This option
ends up being the most seamless since it works like a traditional flow
without any special instructions to the user.
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
Has anybody done any spec work around doing oauth from command
line interfaces? We're looking for something where the auth
server can generate text-based challenges that are rendered in the
console window that query for simple text input over possibly
multiple requests. I'm not talking about Resource Owner or Client
Credentials grant. The command line client may not know the
credential types required for a successful token request. It would
be easy to write a simple protocol, but I'd rather just do
something around any existing internet draft or rfc that somebody
has put some thought into. Hope I'm making sense here.
Thanks,
Bill Burke
Red Hat
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>

Hollenbeck, Scott

2017-06-12 13:29:48 UTC

Permalink

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Bill Burke
Sent: Monday, June 12, 2017 9:23 AM
To: Aaron Parecki <***@parecki.com>
Cc: OAuth WG <***@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] oauth with command line clients

I've read about these techniques, but, its just not a good user experience. I'm thinking more of something where the command line console is the sole user agent and the auth server drives a plain text based interaction much like an HTTP Server drives interaction with HTML and the browser.

This isn't anything complex. It should be a simple protocol, but I'd like to piggy back on existing solutions to build some consensus around what I think is a common issue with using OAuth. If there isn't anything going on here in the OAuth group surrounding this, would be willing to draw up a Draft if there is interest.

[SAH] Iâm certainly interested! I have a use case for federated client authentication and authorization for the Registration Data Access Protocol (RDAP) that has the same need for command line web service clients like wget and curl.

Scott

David Waite

2017-06-12 16:20:36 UTC

Permalink

FYI, A few years ago I did a demonstration on OpenID Connect at Cloud Identity Summit using a collection of bash scripts and command-line utilities (nc, jq). I used the macOS system command âopenâ to launch a browser, and netcat to field the response as a poor manâs HTTP endpoint. The code for that presentation is at https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dynamic-Client-Registration

A few options for the user challenge/consent portion of the authentication are:
- pop up the system browser (you can use window.close() to dismiss on redirect back to your client) - thats the one I used.
- device flow
- use a console browser like lynx or ELinks (which has rudimentary ecmascript support at a fairly big cost)
- use non-HTML request/response API (around some custom MIME type) to drive a user agent through the authentication/scope approval/etc stages of your AS
- punt and use resource owner credentials grant.

-DW

Post by Hollenbeck, Scott
Sent: Monday, June 12, 2017 9:23 AM
Subject: [EXTERNAL] Re: [OAUTH-WG] oauth with command line clients
I've read about these techniques, but, its just not a good user experience. I'm thinking more of something where the command line console is the sole user agent and the auth server drives a plain text based interaction much like an HTTP Server drives interaction with HTML and the browser.
This isn't anything complex. It should be a simple protocol, but I'd like to piggy back on existing solutions to build some consensus around what I think is a common issue with using OAuth. If there isn't anything going on here in the OAuth group surrounding this, would be willing to draw up a Draft if there is interest.
[SAH] Iâm certainly interested! I have a use case for federated client authentication and authorization for the Registration Data Access Protocol (RDAP) that has the same need for command line web service clients like wget and curl.
Scott
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

Bill Burke

2017-06-12 21:38:46 UTC

Permalink

Post by David Waite
FYI, A few years ago I did a demonstration on OpenID Connect at Cloud
Identity Summit using a collection of bash scripts and command-line
utilities (nc, jq). I used the macOS system command ‘open’ to launch a
browser, and netcat to field the response as a poor man’s HTTP
endpoint. The code for that presentation is at
https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dynamic-Client-Registration
A few options for the user challenge/consent portion of the
- use non-HTML request/response API (around some custom MIME type) to
drive a user agent through the authentication/scope approval/etc
stages of your AS

This is the option I'm interested in. Something simple around 401
challenges, text/plain mime type, and simple stdin processing. I"ll
post what I'm thinking of if its appropriate. A colleague pointed me to
SASL + HTTP [1], but not sure if that's what I'm looking for.

Thanks everybody,

Bill

[1] https://tools.ietf.org/html/draft-nystrom-http-sasl-09

Justin Richer

2017-06-12 18:22:20 UTC

Permalink

I second the recommendation to use the device flow for this kind of
system. The commandline client would print out a text string for the
user to enter into their browser elsewhere.

If you can pop up a system browser then it's even easier and you can
just use the auth code flow, but it's a lot to assume that a commandline
app can have that kind of capability available to it. Printing out a
string? That's easy and universal. That's why I say go with the device flow.

The thing is, at the end of the day, you need the user to authenticate
to the AS if you're going to get delegated access from them. That's
really the whole point of the OAuth protocol, after all. So you can
either do that in a local browser of some kind (like popping a system
browser), on another device (with the device flow), or you can be evil
and use the username/password grant and just steal the user's
credentials yourself. If it's not clear, I don't recommend that,
basically ever.

-- Justin

Phil Hunt

2017-06-12 18:34:16 UTC

Permalink

+1

The point of OAuth is to break away from using UID/Password (basic auth).

The device flow is the best way to allow stronger authentication of the authorizing user while still allowing a limited input device (e.g. command line) to work.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid

I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.
If you can pop up a system browser then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.
The thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.
-- Justin

* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddevice-2Dflow&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=gWeHcqrhQt-ijJ5-UXHxML5rMtR05GjKVyxqZBEeQAM&e=> which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
* The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.
----
Aaron Parecki
aaronparecki.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__aaronparecki.com&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=>
@aaronpk <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=g5RjhR9W1VYt00S4dV0t9ijZ4gC4HE93waQ_t7mUzUs&e=>
Has anybody done any spec work around doing oauth from command line interfaces? We're looking for something where the auth server can generate text-based challenges that are rendered in the console window that query for simple text input over possibly multiple requests. I'm not talking about Resource Owner or Client Credentials grant. The command line client may not know the credential types required for a successful token request. It would be easy to write a simple protocol, but I'd rather just do something around any existing internet draft or rfc that somebody has put some thought into. Hope I'm making sense here.
Thanks,
Bill Burke
Red Hat
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=>

Dick Hardt

2017-06-12 18:59:33 UTC

Permalink

+1 to the device flow if you can't pop open a system browser.

If you can pop open a system browser, then a more standard flow is a better
CX.

Post by Phil Hunt
+1
The point of OAuth is to break away from using UID/Password (basic auth).
The device flow is the best way to allow stronger authentication of the
authorizing user while still allowing a limited input device (e.g. command
line) to work.
Phil
Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com
I second the recommendation to use the device flow for this kind of
system. The commandline client would print out a text string for the user
to enter into their browser elsewhere.
If you can pop up a system browser then it's even easier and you can just
use the auth code flow, but it's a lot to assume that a commandline app can
have that kind of capability available to it. Printing out a string? That's
easy and universal. That's why I say go with the device flow.
The thing is, at the end of the day, you need the user to authenticate to
the AS if you're going to get delegated access from them. That's really the
whole point of the OAuth protocol, after all. So you can either do that in
a local browser of some kind (like popping a system browser), on another
device (with the device flow), or you can be evil and use the
username/password grant and just steal the user's credentials yourself. If
it's not clear, I don't recommend that, basically ever.
-- Justin
* The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-
flow
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddevice-2Dflow&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=gWeHcqrhQt-ijJ5-UXHxML5rMtR05GjKVyxqZBEeQAM&e=>
which is what you see on browserless devices like the Apple TV logging in
to a cable provider from your phone. A short code is generated and
displayed on the screen, you launch a browser on your phone and enter the
code. This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the
authorization URL on the command line prompt and instructing the user to
open it in a browser. The redirect URI is a hosted web page that displays
the authorization code and instructs the user to paste it back at the
terminal.
* The command line app can launch an HTTP server on localhost and use that
as the redirect URL for the authorization code flow. This option ends up
being the most seamless since it works like a traditional flow without any
special instructions to the user.
----
Aaron Parecki
aaronparecki.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__aaronparecki.com&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=>
@aaronpk
<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=g5RjhR9W1VYt00S4dV0t9ijZ4gC4HE93waQ_t7mUzUs&e=>

_______________________________________________
_______________________________________________
OAuth mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=
eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

Bill Burke

2017-06-17 14:24:23 UTC

Permalink

I guess the auth code flow could be used with the command line tool
using the OpenID Connect "display" parameter with a value of
"command-line" or "text" or something when it makes its auth request. I
could go the route of defining what "command-line" display value would
mean in OIDC land. Awkward from an implementation point of view, but a
viable path.

Quite honestly, I just dont' see how any app developer would want to
require device flow. It is a bad user experience. I would even go as
far to say that the device flow is an unacceptable user experience.
Especially if cut and paste is not possible and the human has to enter
in some kind of long cryptic code by hand.

Post by Justin Richer
I second the recommendation to use the device flow for this kind of
system. The commandline client would print out a text string for the
user to enter into their browser elsewhere.
If you can pop up a system browser then it's even easier and you can
just use the auth code flow, but it's a lot to assume that a
commandline app can have that kind of capability available to it.
Printing out a string? That's easy and universal. That's why I say go
with the device flow.
The thing is, at the end of the day, you need the user to
authenticate to the AS if you're going to get delegated access from
them. That's really the whole point of the OAuth protocol, after all.
So you can either do that in a local browser of some kind (like
popping a system browser), on another device (with the device flow),
or you can be evil and use the username/password grant and just steal
the user's credentials yourself. If it's not clear, I don't recommend
that, basically ever.
-- Justin

Post by Aaron Parecki
https://tools.ietf.org/html/draft-ietf-oauth-device-flow
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddevice-2Dflow&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=gWeHcqrhQt-ijJ5-UXHxML5rMtR05GjKVyxqZBEeQAM&e=>
which is what you see on browserless devices like the Apple TV
logging in to a cable provider from your phone. A short code is
generated and displayed on the screen, you launch a browser on your
phone and enter the code. This would work just as well from the
command line on the same device.
* I've also seen apps use the authorization flow, by displaying the
authorization URL on the command line prompt and instructing the
user to open it in a browser. The redirect URI is a hosted web page
that displays the authorization code and instructs the user to paste
it back at the terminal.
* The command line app can launch an HTTP server on localhost and
use that as the redirect URL for the authorization code flow. This
option ends up being the most seamless since it works like a
traditional flow without any special instructions to the user.
----
Aaron Parecki
aaronparecki.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__aaronparecki.com&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=>
@aaronpk
<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=g5RjhR9W1VYt00S4dV0t9ijZ4gC4HE93waQ_t7mUzUs&e=>
Has anybody done any spec work around doing oauth from command
line interfaces? We're looking for something where the auth
server can generate text-based challenges that are rendered in
the console window that query for simple text input over
possibly multiple requests. I'm not talking about Resource
Owner or Client Credentials grant. The command line client may
not know the credential types required for a successful token
request. It would be easy to write a simple protocol, but I'd
rather just do something around any existing internet draft or
rfc that somebody has put some thought into. Hope I'm making sense here.
Thanks,
Bill Burke
Red Hat
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Justin Richer

2017-06-19 16:02:57 UTC

Permalink

While it does add a vector for user error, the codes arenât long and cryptic. Most implementations are 6 or 8 characters, and itâs recommended that they be case insensitive and not have ambiguous characters (I vs 1, O vs 0). And they should be all low ASCII, even just a subset of uppercase letters as suggested on the spec itself. These arenât authorization codes or access tokens, which are meant to be machine-readable and high entropy.

â Justin

I guess the auth code flow could be used with the command line tool using the OpenID Connect "display" parameter with a value of "command-line" or "text" or something when it makes its auth request. I could go the route of defining what "command-line" display value would mean in OIDC land. Awkward from an implementation point of view, but a viable path.
Quite honestly, I just dont' see how any app developer would want to require device flow. It is a bad user experience. I would even go as far to say that the device flow is an unacceptable user experience. Especially if cut and paste is not possible and the human has to enter in some kind of long cryptic code by hand.

I second the recommendation to use the device flow for this kind of system. The commandline client would print out a text string for the user to enter into their browser elsewhere.
If you can pop up a system browser then it's even easier and you can just use the auth code flow, but it's a lot to assume that a commandline app can have that kind of capability available to it. Printing out a string? That's easy and universal. That's why I say go with the device flow.
The thing is, at the end of the day, you need the user to authenticate to the AS if you're going to get delegated access from them. That's really the whole point of the OAuth protocol, after all. So you can either do that in a local browser of some kind (like popping a system browser), on another device (with the device flow), or you can be evil and use the username/password grant and just steal the user's credentials yourself. If it's not clear, I don't recommend that, basically ever.
-- Justin

_______________________________________________
OAuth mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=>