Command line login using Authorization Code Flow

[sp-manuel-jurado]

Hi,

Would It be possible to log against the vouch proxy from the command line, making a script like https://developer.okta.com/blog/2018/07/16/oauth-2-command-line and being able to obtain access_token(jwt) (using response headers like X-Vouch-IdP-IdToken, X-Vouch-IdP-AccessToken)?

I see that /validate can also validate by access_token (as querystring) or Authentication Bearer (header):

• https://github.com/vouch/vouch-proxy/blob/master/handlers/validate.go#L36
• https://github.com/vouch/vouch-proxy/blob/master/pkg/jwtmanager/jwtmanager.go#L221

It would be very useful for me to be able to make secure API requests from the console to the server bypassing the access_token(jwt) (instead of the browser cookie).

Thanks in advance.

[bnfinet]

@sp-manuel-jurado that's an interesting use case

Seems feasible to integrate a light client into a cmdline program which just handed off login to VP...

I see you've found #362. I think that's a better solution overall but lets run with this for just a second..

If you send the user to
http://vouch.yourdomain.com/login?url=https://${CMDLINE_WEBSERVER}

You would get a VP issued JWT in the form of a cookie from /auth/$STATE at the end of the flow.

If you hand that cookie to /validate you would get either a 200 OK or a 401 Unauthorized

We could improve /auth to offer the jwt back as a header though you should be able to just hand the cookie back as-is in any of the methods you outlined and it should work.

@aaronpk what do you think of this setup? Does this fit your original intention with that blog post?

But let me say again I think the real solution is #362. I'll respond to your note there in just a moment.

[bnfinet]

closing in favor of #362

[sp-manuel-jurado]

Hi, @bnfinet excuse me for the delay, I've been out for a few weeks.

closing in favor of #362

IMHO both features should coexist:

• Server-to-server (no user): The Client Credentials flow is recommended for server-side (AKA confidential) client applications with no end-user, which normally describes machine-to-machine communication. Your application needs to securely store its Client ID and secret and pass those to Okta in exchange for an access token. Further info.
• Client-to-server (user) (either using a cookie or using the JWT directly as Authorization header). If you are building a server-side (or web) application that is capable of securely storing secrets, then the Authorization Code flow is the recommended method for controlling access to it. Further info.

We could improve /auth to offer the JWT back as a header though you should be able to just hand the cookie back as-is in any of the methods you outlined and it should work.

So It would be very useful for us (In fact It would be nice to have more info like the state to refresh token in case it is necessary)

@bnfinet What do you think about this? (maybe I'm missing something)
And sorry for the delay, again.

[bnfinet]

@sp-manuel-jurado yeah that all sounds good. Non-browser Authorization Code Flow seems like a fine addition to VP. Is this something you're interested in working on?