Auth 101 - Longhorn PHP

@maccath | Katy Ereira | #LonghornPHP
Auth 101.
What even is Auth anyway?

View Slide

What do we mean by ‘auth’?
● Authentication?
● Authorisation?
● What’s the diﬀerence?

View Slide

Authentication vs Authorisation
Authentication (authn) is used to determine that…
● Your identity can be veriﬁed
● Your credentials match what is held on ﬁle
● Your request is authentic

View Slide

Authentication vs Authorisation
Authorisation (authz) is used to determine that…
● You are admitted entry to a protected area
● You possess the correct key
● You are permitted access to a resource
● You have been authorised to perform an action

View Slide

Remember:
Authentication leads to authorisation, but authorisation never leads to
authentication.

View Slide

Authentication

View Slide

Authentication Factors

View Slide

Something You Know
● A username and password
● A PIN
● Answer to a secret question

View Slide

Something You Have
● A key
● A certiﬁcate
● Access to a smart device
● An email address or phone number

View Slide

Something You Are
● Biometrics: ﬁngerprints, voice, retina
● Location-based
● Facial recognition

View Slide

The Humble Password

View Slide

Let’s talk about password security…
● Passwords must be strong
● Passwords must be hashed and salted before storing
● Passwords should not be the only authentication factor

View Slide

Salting & hashing a password
$password = $_POST['password']; // The plaintext password.
$algorithm = PASSWORD_DEFAULT; // Choose an algorithm.
$hash = password_hash($password, $algorithm); // Hash and salt it.
// You may now store the value of $hash in your database!
save-password.php

View Slide

The Password Hash Function
● Creates a salt automatically so you don’t have to!
● Returns the salt in the hash so no separate storage required.
● Hash contains the algorithm parameters used to generate it.
$2y$07$CCk9VkXcWxRIhy90tY21SeYjnHxoe0t/8.XQ3IV5KEelwrFTNu4Ge

View Slide

Supported Algorithms
● password_hash() only supports strong hashing algorithms.
● PASSWORD_DEFAULT is the PHP default algorithm; this can change if
something stronger comes along. Currently, it is PASSWORD_BCRYPT
● You can also use PASSWORD_ARGON2I and PASSWORD_ARGON2ID if
PHP was compiled with Argon2 support.

View Slide

Verifying a password
$password = $_POST['password']; // The plaintext password
/** @var object{hash: string} $user */
$hash = $user->hash; // The stored password hash
$valid = password_verify($password, $hash);
verify-password.php

View Slide

Bonus points - rehashing!
// … cont’d
if ($valid && password_needs_rehash($hash, PASSWORD_DEFAULT)) {
// Create a new hash, and replace the old one
$user->hash = password_hash($password, PASSWORD_DEFAULT);
}
verify-password.php

View Slide

Application
User
credentials
Auth Handler
Action Error 401
Password Verify

View Slide

https://xkcd.com/538/

View Slide

Multi-factor Authentication / 2FA
Anyone can obtain and use a password; it doesn’t verify anything!
Two or more diﬀerent authentication factors goes much further in determining
the authenticity of a user.

View Slide

Application
User
Action
Error 401
Auth Handler
credentials
answer
Password Verify
Challenge
Verify

View Slide

Challenge Ideas
● TOTP - Time-based One Time Password
● Email conﬁrmation link
● SMS OTP

View Slide

Remember:
Passwords verify nothing; use two or more factors to really authenticate
your users!

View Slide

Persisting State

View Slide

Using Sessions
A session is a way of persisting data between requests. Session data is stored
server-side.
When a session is created in PHP, a random session ID is generated. The ID is
stored in a `PHPSESSID` cookie.

View Slide

Application
Auth Handler
User
Action
Error 401
Create Session
Verify
req. with credentials
resp. with session ID
Session Store

View Slide

Creating a logged in session
// ...cont’d
$valid = password_verify($password, $hash);
if ($valid) {
session_start();
$_SESSION['loggedIn'] = true;
}
login.php

View Slide

Application
Auth Handler
User
Action
Error 401
Update Session
Check Session
req. with session ID
Session Store

View Slide

Checking if a user is logged in
session_start();
if ($_SESSION['loggedIn'] === true) {
// User is logged in!
}
login.php

View Slide

Logging out
session_start();
unset($_SESSION['loggedIn']);
// User is no longer logged in!
logout.php

View Slide

“
Using JWTs
JSON Web Tokens are an open, industry standard RFC 7519 method
for representing claims securely between two parties.
Reference: https:/
/jwt.io/

View Slide

Using JWTs
A JWT contains data, similar to the data a PHP Session might contain. The
diﬀerence is that JWTs do not require server storage.
Using a shared secret, JWTs can be decoded and validated across multiple
services.

View Slide

Application
Auth Handler
User
Response Error 401
req. with credentials
Create JWT
Verify
resp. with JWT

View Slide

Application
Auth Handler
User
Action Error 401
Validate JWT
req. with JWT

View Slide

Sample JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODk
wIiwibmFtZSI6IkthdHkiLCJpYXQiOjE1MTYyMzkwMjJ9.DQvkUBA1vHZSIJ
46Ue1yXibd0rWoylJFztYrXC50h2A

View Slide

Part 1 - Header
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{
"alg": "HS256",
"typ": "JWT"
}

View Slide

Part 2 - Payload (Claims)
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkthdHkiLCJpYXQiOjE1MTYyMzkwMjJ9
{
"sub": "1234567890",
"name": "Katy",
"iat": 1516239022
}

View Slide

Part 3 - Signature
DQvkUBA1vHZSIJ46Ue1yXibd0rWoylJFztYrXC50h2A
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
my-super-secret
)

View Slide

Q?
A. By comparing the signature to a hash using your shared secret, you can
verify that the contents of the JWT are authentic and have not been
tampered with.
How can I trust that a JWT is authentic?

View Slide

Registered Claims
JWTs have a set of registered (useful, interoperable) claims, which include:
○ aud - audience
○ nbf - not before
○ iss - issuer
○ exp - expiry
○ iat - issued at
○ sub - subject

View Slide

Custom Claims
It is possible to add your own custom claims to a JWT. Custom claims should
be namespaced to avoid collisions. It is recommended to namespace claims
using a domain you control.
{
"sub": "Katy",
"https://katy-ereira.co.uk/fav_color": "purple"
}

View Slide

Other Considerations
● Access tokens are sent in request headers; many servers do not support headers larger
than 8kB. Try and keep your JWT and its claims as minimal as possible!
● JWTs cannot be invalidated, but they can expire. Set a short expiry time and validate
against this to mitigate interception.
● Claims within JWTs are only base64 encoded. Don’t encode anything sensitive!

View Slide

Remember:
Sessions require state storage; JWTs are stateless and can be veriﬁed
across multiple services using a shared secret.

View Slide

Authorisation Strategies

View Slide

● ABAC
● RBAC
● ReBAC

View Slide

● ABAC - Attribute Based Access Control
● RBAC - Role Based Access Control
● ReBAC - Relationship Based Access Control

View Slide

Attribute Based Access Control
“My age is over 18 therefore I am permitted to play the lottery”
● Very granular and ﬂexible.
● Can be used to create complex access conditions.
● Can consider of a large number of attributes
○ nature of actions, time, location, relationships, roles, ages, etc.

View Slide

Role Based Access Control
“I am a site administrator therefore I am authorised to delete posts”
● Applies set permissions to generalised groups of people
● Less complex access conditions when compared with ABAC
● May be harder to scale as the number of roles and permissions grow

View Slide

Relationship Based Access Control
“I teach this student, so I may view their reports”
● Easy to reason about
● No need to assign roles or attributes
● Harder to scale; when relationship structures evolve, so must the access control

View Slide

OAuth 2.0

View Slide

“
OAuth 2.0
OAuth 2.0 is the industry-standard protocol for authorization.
OAuth 2.0 focuses on client developer simplicity while providing
speciﬁc authorization ﬂows for web applications, desktop
applications, mobile phones, and living room devices.
Reference: https:/
/oauth.net/2/

View Slide

Resource Owner
A Resource Owner is a user or system that owns a protected resource.
A Resource Owner can Authorise access to the resources they own.

View Slide

Client
A Client is a system that requires access to resources owned by a
Resource Owner and protected by a Resource Server.
To access resources, a Client must be Authorised by the Resource Owner.

View Slide

Auth Server
The Auth Server receives requests from the Client for access to protected
resources.
It issues access credentials upon successful Authentication of, and
Authorisation by the Resource Owner.

View Slide

Resource Server
The Resource Server protects the Resource Owner's resources.
It receives resource access requests from the Client. The Client sends
access credentials along with its request, which the Resource Server
veriﬁes.
Upon veriﬁcation, the Resource Server returns the requested resources.

View Slide

Auth Server
Client Resource Owner
Authorise
Authenticate
Access Credentials
Resource Server
Verify Credentials
Action 401
(e.g. mobile app)
(e.g. an API)
(e.g. a user)
(e.g. Google accounts)

View Slide

OAuth 2.0 Providers

View Slide

Providers?
There are many existing providers of OAuth 2.0 implementations. These
include: Facebook, Google, LinkedIn, Instagram, etc.
By registering a Client, you can ask a Resource Owner for Authorisation using
the provider’s OAuth Server. An authenticated user’s email address may be all
your Resource Server needs to validate and fulﬁl the request.

View Slide

Creating an OAuth 2.0 Provider?
Of course, you can implement your own OAuth 2.0 provider by following the
OAuth 2.0 speciﬁcation.
For now, let’s assume we are integrating with an existing OAuth 2.0 provider
such as Google, and that our services have their own database of users with
email addresses that belong to Google accounts.

View Slide

Grants

View Slide

Grants
There are various ways for a resource owner to grant access to a protected
resource via an OAuth provider.
Each method for receiving authorisation to access to a protected resource is
called a ‘Grant’.

View Slide

Authorisation Code Grants
A single-use authorisation code is exchanged for an access token. The authorisation
code itself can be securely transferred around a server-side application.
Proof Key for Code Exchange (PKCE) is an additional step that makes authorisation
code grants more secure for mobile and single-page applications.

View Slide

Auth Server
Client Resource Owner
Authorise
Authenticate
Generate Code
Resource Server
Validate JWT
Action 401
Verify Code
Generate JWT

View Slide

Resource Owner Credentials Grant
For absolutely trusted clients only, the Resource Owner can give its own
credentials to the Client (i.e. their username and password), which the Client
can then use to authorise with the Auth Server.

View Slide

Auth Server
Client
Resource Owner
Verify Credentials
Generate JWT
Resource Server
Validate JWT
Action 401

View Slide

Q?
A. You can’t; which is why the OAuth working group recommends against
using or enabling this grant in your OAuth server, and it has been
intentionally omitted from the draft OAuth 2.1 spec.
Ref: https:/
/datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.4
How can I trust that the client will store
the user’s credentials securely?

View Slide

Client Credentials Grant
A Client uses its own credentials (e.g. a client ID and secret) to authorise with
the Auth Server.
This type of grant is used for non-interactive services that do not involve a
Resource Owner; e.g. machine-to-machine operations.

View Slide

Auth Server
Client
Verify Credentials
Generate JWT
Resource Server
Validate JWT
Action 401

View Slide

Device Authorisation Grant
Can be used to authorise browserless devices, such as smart TVs.
Does not require any interaction with the Auth Server; instead, depends on the
Resource Owner authenticating and authorising the device manually.

View Slide

Client Auth Server
Resource Owner Verify Credentials
Resource Server
Validate JWT
Action 401
Issue
Code
Verify Code
Request Access
Issue
JWT
Grant Access
Granted?
display code
manual auth

View Slide

Refresh Token Grant
A previously authorised Client can refresh its own grant using a securely
stored, longer lived refresh token.
A Client can maintain access to protected resources without having to ask the
Resource Owner for re-authorisation.

View Slide

Auth Server
Client
Verify Refresh
Token
Generate JWT
Resource Server
Validate JWT
Action 401
Resource Owner
prior auth

View Slide

Remember:
You can use multiple grant types depending on the interaction required
between your services.

View Slide

Other Security Considerations

View Slide

Other Considerations
● Use HTTPS - always!
● Validate redirect URLs,
● Short-lived access tokens, long lived refresh tokens
● Invalidate longer lived tokens.
● Don’t expose private information.

View Slide

It’s all too complicated!

View Slide

There’s
saas for
that

View Slide

Time for a recap...
● Authentication vs Authorisation
● Authentication Factors
● Password Security
● Authorisation strategies
● Sessions vs. JWTs
● OAuth 2.0 Spec

View Slide

… later, in Auth 102?
● OpenID
● Identity Access Management (IAM)
● Threat detection
● Integrating with Auth0
● … what else did I miss?

View Slide

Further Reading & Helpful Resources
● Decode and validate JWTs: https:/
/jwt.io
● OAuth simpliﬁed: https:/
/oauth.com
● Auth0 - auth SaaS: https:/
/auth0.com
● OWASP Auth:
https:/
/cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

View Slide

https://joind.in/talk/eb34d

View Slide

Auth 101 - Longhorn PHP

Auth 101 - Longhorn PHP

Katy Ereira

More Decks by Katy Ereira

Other Decks in Programming

Featured

Transcript