I am learning about OAuth 2 and OpenID Connect. Reading the documentations I feel that the specification of OpenID Connect leaves some blank space regarding the End-User Authentication.

The spec states:

The methods used by the Authorization Server to Authenticate the End-User (e.g. username and password, session cookies, etc.) are beyond the scope of this specification.

For an Authorization Server implementation I was wondering on what common End-User Authentication protocols there are.

Assuming that TLS is in places in between the End-User app and the Authorization Server, aswell as the OAuth 2 Relying Party, I still feel not comfortable using a plain username/password scheme, as there are much more sophisticated schemes available, such as Challenge/Response or even Public-Key Based Authentication.

My wishlist for the authentication scheme would involve the following requirements:

  • No credentials stored in plaintext on the server side, assuming that the server's database can be hacked
  • The least amount of plaintext credentials communicated over the wire
  • An additional layer of protection (beneath TLS) for Replay Attacks

Overall I would like to remain in the scope feasible for mobile apps used by John Doe, e.g. a PKI structure with a secure certificate exchange involving a different channel or such will be overkill. Also two-factor authentication would be nice but shouldn't be mandatory in the first stage.

Could you please point me to protocols / standards that I overlooked or haven't found yet. Thanks!

Edit: I just discovered SCRAM, which looks promising. If there are other methods I should be aware of, I appreciate your help.

  • If you are using TLS, there will not be any clear-text passwords on the wire. Are you concerned sending encrypted passwords? Do you have reason to mistrust your TLS connection? Commented Feb 27, 2016 at 16:28
  • Well not really, yet I would like to seek the optimum solution on each layer within my constraints really. SCRAM seems to protect against Man in the middle, replay and eavesdropping on credentials even if TLS would fail, which is nice from a theoretical view. Commented Feb 27, 2016 at 17:03
  • Theory is great, but, in practice, going with the the tried and true methods is generally most secure. Commented Feb 27, 2016 at 17:04