Skip to end of banner
Go to start of banner

Session authentication by email

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

We're going to add a feature that will allow apps to work without the user needing to create or enter a password.

How it will work on the client

First install

  1. Participant installs the app
  2. After consent process, app generates password to sign up user
  3. User consent is submitted, app has session
  4. When session expires, the app uses the generated password to re-authenticate

Reinstalls

  1. Participant installs the app on new device or deletes/reinstalls 
  2. Participant opens app, says “hey I already have an account, here’s the email address” 
  3. App tells server “send me a magic link to this email address" 
  4. App tells participant “check your email for a magic link” 
  5. Participant has to go to email on phone and tap magic link, which takes them to the app to sign them in 
  6. The app generates a new random password and includes it in the magic link sign-in call

How it will work on the server

Two new endpoints will be introduced:


POST/v3/auth/session/request
auth
no authentication, public endpoint
body
{ "email": "<email.address>" }
returns202Accepted (email will be sent)

429Too many requests sent (being rate-limited, no further email will be sent)

This endpoint will need to rate-limit the frequency of submissions for the same email address (the same Redis entry with a TTL can serve both as a rate limit, and an expiration for the validity of the token, probably one minute). It will also need to verify the email is active in the study before sending an email.


POST/v3/auth/session
auth
no authentication, public endpoint
body
{ "email": "<email.address>", "password": "<password>", "token" : "<token>" }
returns200with user session

412with user session

404
{ "statusCode": 404, "entityClass": "Account", "message": "Account not found.", "type": "EntityNotFoundException" }

If the token has been issued, retrieve the user's identity and return a session. Optionally, if a password value has also been submitted, reset the password before returning the session.

Study

Study will have a new email template, the sessionVerificationTemplate, which will allow researchers to create a message and the message can include a link. If the app needs, for example, to have a link with a subdomain, like https://myApp.sagebridge.org/mobile/verify.html?token=<sometoken>, they will be able to add that. There should be a default using web services.sagebridge.org.

Verify the template has a ${token} string in it somewhere to substitute the token.

I can't think of a reason why we would enable/disable this functionality... either an app supports it or it doesn't.

AuthenticationService

methodDescription
initiateSessionVerification(String email)
  1. If email present, through RateLimitExceededException
  2. create token, store in Redis mapped to email, TTL 1 minute
  3. send email using study template to supplied email address
verifySession(String email, String password, String token)
  1. Retrieve token from Redis using email
  2. If email or token missing, or token doesn't match supplied token, through 404
  3. Update password, if supplied
  4. Delete Redis entry
  5. Return a user session



  • No labels