Leaving the State: Sessionless (Stateless) Authentication in D8 DrupalCon Nashville 2018

These Guys Dr J Daverth Technical Lead, Whole Foods Market D.O.: dr-jay BitBucket: drjdaverth LinkedIn: drjdaverth Adam Weingarten Senior Technical Architect, Acquia D.O.: adam.weingarten GitHub: aweingarten LinkedIn: adam.weingarten

Brought to you by

What are we going to talk about? ● Why scaling authenticated traffic is hard? ● What is sessionless auth? ● How can you use it to manage a single login to multiple sites ● Working with an external auth provider (Janrain) ● PIIaaS! Storing PII as a Service in an API. ● Proxying web-service calls - don’t do it! ● How to delegate oauth token

Case Study – International Retail Brand Launched July 2012 on Drupal 7 Designed for a much more static world Full page refreshes Not service based

Deep dive in the issues on D7 Primitive Janrain Social Integration: Really heavy weight on page load Bloated DB. Copies took forever. Stored unnecessary PII Authenticated experiences required full page loads. Meant things weren’t cacheable.

D8 High-level Goals Technical Drivers Support 10% Authenticated Traffic SSO between D7 and D8 Personalized Digital Experience Mobile / Responsive Experience

Back to the Basics Scaling Anonymous Traffic Is Easy Can let CDN do the lifting: Fastly, Akamai, CloudFlare. Varnish in front of your webs Hit your origin. Store the information at Varnish and CDN. Caching solves all the problems.

What is a Session? The sequence of interactions between client and server, or between user and system; the period during which a user is logged in or connected. -- Thus spoke Wikipedia

What is a PHP Session? $_SESSION super global Start with session_start() early in your PHP script. Drupal wraps it and stores data across requests in the DB Uses a cookie value to ID you

What does it Look Like?

Why are Sessions a PAIN? HTTP/1.1 200 OK Age: 0 Cache-Control: must-revalidate, no-cache, private Via: 1.1 varnish-v4 Connection: keep-alive X-Cache: MISS, MISS, MISS X-Cache-Hits: 0, 0 X-Timer: S1508437362.252176,VS0,VE296 Bypasses cache. No cache for you!

Under Pressure Your DB and your webserver

Opposition of Forces New experience requires personalization Our infrastructure sucks at personalized data

Oh, did you forget? We also need to support seamless login to D7 and D8 Login to one system, and let the second system hit a service to confirm a user is authenticated Set a token that both sites can read

Solutions not problems After we have crushed your soul let’s build you back up.

Traditional Auth Get session Yeah they’re cool Data Authenticates MySql with Session tables IDP Drupal 8 Return session data Return personalized data

Stateless (Sessionless) Auth User authenticates with something. Once they pass the bouncer give them an encrypted token. User can’t read it Any time they try to do something special they present the token. Then the bouncer decrypts it and lets them through.

From Drupal’s POV

What is in the Magic Encrypted Token? Anything that might live in a PHP Session or User table API UserIDs Session Expiration time

How does this let me do D7 and D8? Assuming that the 2 sites are on the same domain or subdomain Both sites can read the cookie Shared decryption key both can read it. I login on D8 -> I go to a page being hosted at D7

I used to log people out by truncating the session table. Now what??

We can show you how to prevent world domination by zombies Umm yeah that…. HowTake current time + session lifetime. If the timestamp in the decrypted cookie < current time + session lifetime. Then send back an expiration message and handle it on the frontend.

PIIaaS Storing Personally Identifiable Information (PII) as a Service (API)

PII as a Service All personalized content on IOS, Android and Web via API Drupal is a consumer of the API like anyone else No DB calls, no PII unnecessarily stored in Drupal Clear separation of concerns.

Lesson Learned Proxying webservice calls is bad.

Yeah, this is why it’s really bad Latency. Each web-server has a finite number of concurrent PHP procs When you make a webservice call you tie up those procs waiting for a response. Limits transactions per-second.

How do we fix it?

Browser can access the API layer directly, without an intermediary

How scalable?

Very Scalable

Ended up with: Scalable System Separation of concerns: Each part of our stack can focus on doing 1 thing well.

Questions?

Thank you!