search

anvilresearch / connect

A modern authorization server built to authenticate your users and protect your APIs
http://anvil.io
MIT License
361 stars 85 forks source link

password grant type #329

Closed PetrSnobelt closed 8 years ago

PetrSnobelt commented 8 years ago

Hello, I'd like to use "Resource Owner Password Credentials Grant" as described in https://tools.ietf.org/html/rfc6749#section-4.3 but request with grant_type = 'password' like this https://tools.ietf.org/html/rfc6749#section-4.3.2 cause "error": "unsupported_grant_type"

Is this grant type supported? And if not why?

Thank you Petr

christiansmith commented 8 years ago

Hi @PetrSnobelt. Thanks for asking.

There are a few reasons we haven't implemented that grant type. It's part of OAuth 2.0. but not included OpenID Connect (which is a profile of OAuth 2.0). Even the RFC recommends against using it when there's another choice. I think the main reason for caution there is that it involves transmitting passwords between domains. There's just too much opportunity for abuse and misuse.

It's much safer (if passwords can be considered safe at all these days) to simply direct the user agent straight to the auth server. At least that sort of enforces that the passwords are entered into a form where the referrer matches the auth service. Of course you can just forge the referrer header. But we'd rather that people try to circumvent that sort of mechanism than encourage potential vulnerabilities by making it easy.

We're also beginning to work on moving away from password-based auth altogether. Unfortunately that's not a quick problem to solve. FIDO 2.0 looks like it may have the best chance and I'm personally dying to sink my teeth into that new browser native UAF spec. Gotta skate where the puck is going to be :)

May I ask what's your use case that the password grant seems like the way to go?

PetrSnobelt commented 8 years ago

Hi @christiansmith, thank you for such fast reply ;-)

Main use case for this grant type is that we like to use anvil as replacement for custom authentication in our apps (classic web app, SPA web app, desktop app, web api) and this change should be "invisible" to our users.

We don't want to start redirecting users to anvil and then back in our apps ...

christiansmith commented 8 years ago

@PetrSnobelt – You could do the same thing we're doing for form based authentication in our CLI, which is POST to https://YOURANVILSERVER/signin and forge the referrer header to match. It takes a couple extra parameters in addition to the OIDC params in order to do this... ...&provider=password&email=EMAIL&password=PASSWORD.

I'm not saying you should. But you could :)

PetrSnobelt commented 8 years ago

Thank you very much @christiansmith I reuse https://github.com/anvilresearch/connect-cli/blob/master/lib/plugins/login.js and it works perfectly.