OAuth 2.0 or OpenID Connect

Using an established protocol like OpenID Connect (OIDC) rather than password-based authentication offers a convenient user experience and minimises the risks associated with creating, storing and updating passwords in your own systems.

Even the best password implementation can’t prevent users from reusing passwords across multiple websites. If one of their accounts get compromised elsewhere, an attacker can still hijack their account on our system.

OpenID is a decentralised standard, so it’s not controlled by any service provider like Google, Facebook, Apple etc. Passwords are never shared between websites, so if an account is compromised, changing the OpenID password immediately stops the attack from spilling over.

OIDC is an extension of OAuth 2.0 which adds login and profile information on top of the authorisation function that OAuth 2.0 has, in order to establish the identity of the user, hence OIDC providers are also called Identity Providers. The flows are similar, except that the client application receives both an Access Token and an ID token (a JWT token with a payload and some specific claims).

Choose a solution in line with requirements and regulations

Not all businesses have the same risk threshold when it comes to choosing authentication mechanisms. For example, for financial services, there are specific requirements about authenticating both end-users and system users (i.e. admins), for example Strong Customer Authentication and/or MFA with hardware to access internal systems.

Token vs cookie authentication

Traditional websites use cookie-based authentication. Modern single-page web and mobile apps, as well as internal services use API-based authentication, mostly with JSON Web Tokens (JWT). Sometimes, there’s a mixed approach. The thing to remember is that if the web app needs API-based authentication, that API either has to be served from the same domain, e.g. https://example.com/api or the API needs CORS enabled.

Refresh and Access Tokens

JWT tokens can take many forms, like Access Tokens in OAuth 2.0. and Identity Tokens in OIDC.

Identity tokens

They contain information about the user’s identity with a certain provider like Google. The token is signed with the provider’s private key and the application server uses the provider’s public key to verify its integrity. The same principle is applied in the enterprise version of Single Sign-On (SSO), where the SSO service signs the token with its private key. The OIDC protocol also specifies the use of specific JWT claims in the payload, like exp, iss and aud and a nonce to prevent replay attacks. It’s very hard to steal an identity token.

Access tokens

An access token gives a client application access to a protected resource, such as an API, on behalf of the user. An access token comes in two flavours:

1. Reference tokens (opaque)

• They are not tokens, but token IDs. The actual token is stored by a Secure Token Service (STS) in a data store.
• The recipient of the token ID sends it to the STS to retrieve its contents.
• The STS offers better control over the token’s lifecycle and makes it easier to revoke tokens in an emergency e.g. a lost phone or a phishing attack or invalidate tokens when users logout or uninstall an application.

1. Bearer tokens (self-contained)

Sometimes password reset flows are treated as an afterthought and this opens up many attack vectors.

User enumeration and privacy impact

Never reply with “There is no registered user with <username>/<email>” to an account reset request. Leaking who is and who isn’t a user of your business is a bad idea:

• Firstly, it’s a user privacy breach. Maybe your users don’t want to be publicly associated with your company, especially for banking or dating sites.
• Secondly, an attacker can write a script to validate an entire collection of usernames and emails against your website and then spam all your users.

If the user doesn’t exist or enters the wrong email or password, and the system shows an error, use a combination message like “Your credentials don’t match”. This sort of message doesn’t disclose anything about the existence of the email address and doesn’t make it easier for an attacker to guess which field is wrong, like in “Your username is wrong” or “Your password is wrong”.

Password reminders vs resetting passwords

Never remind users their passwords in plain text via emails or SMS. If that password is persistent, there’s a good chance that sending it through an insecure channel can lead to account theft. Someone else could glance over and memorise the user’s email and password, then steal their account. Unencrypted emails and SMS are very unsecure channels.

Numeric reset codes

Magic reset links are user-friendly but they don’t work well in some cases. For example, the user could be signed in Chrome on their desktop, request a password reset link and then open the email on their smartphone Safari browser. This means that the session they initiate on one device is not transferable across the other device via the link. One solution for better usability is to send a numeric code and give users the option to enter a shorter numeric code on their choice of device to finish the password reset flow.

Numeric reset code from Fb