Magic link (one time authentication link) authentication implementation ideas?

UI Builder
1

Has anyone implemented magic link authentication? I have some ideas, but I would appreciate any ideas from folks who might have done this already.

Thanks,
Tim

2

Hi @Tim_Jones ,

You can implement this feature using custom CloudCode services.

You can do the next:

  1. Create a custom CloudCode service which will receive userId, email or other identity value associated with your user. This service will generate some random unique code and store code-userId pair somewhere in the app (DB or Hive for example). Include generated code to the link which will point to your UI page and return created link to the client (directly or send on email, for example).
  2. Create another custom CloudCode service. In this service you should take the code from the link and search by it related user ID. Found user ID you can then use to login user using “login by user ID” method which available only from CloudCode. Result of such login call will contain user data and user token which should be used for next API calls as authenticated user.
  3. Custom logic on the page from step #1 should read code and make a call to the service from step #2, receive response with user token and then perform other required actions.

After step #3 user will be authenticated in your application.

Regards, Andriy

3

Thanks, @Andriy_Konoz!

Would you put step #2 in a reusable component that gets added to every page to check the query string for the auth code?

Now that I think about it, maybe it needs to be a function that is included On Page Enter?

How would you specifically implement the login part?

Tim

4

@Tim_Jones ,

Would you put step #2 in a reusable component that gets added to every page to check the query string for the auth code?

It seems to me redundant. This part is related to obtaining of user auth token and should be called only when you exchanging “one-time” link to auth token. I would rather put check of validity of current user session in “On Page Enter” event at most and if it not valid - direct user to the login screen. But it can be not necessary since in case of invalid user session you will receive error which will indicate that user should be relogined.

How would you specifically implement the login part?

Implementation completely depends on your requirements which are unknown to me.

For example, it can be used for passwordless login - user enters only email and then receives link on his email. It can be implemented using custom UI login page which will call service from step #1. Is it answers your last question?

Regards, Andriy

5

@Andriy_Konoz

I wasn’t clear on my question. Where would you put -

exchanging “one-time” link to auth token

For example, the user gets a link in their email. I want them to end up on “mainPage”. I was thinking you’d link them to myapp.com?page=mainPage&auth=ksklj3l344. mainPage would check if PageData has an auth string, and do the exchange of the auth string for the auth token.

Are you suggesting something else?

Tim

6

@Tim_Jones ,

I am suggesting you to add one more page (step #3) which will be responsible for calling your custom service from step #2, setting received user auth token to your app session storage and then redirecting user to your “main page”.

Flow for user will look in the next way:

  1. User enters its email on login page
  2. Login page calls service from step #1 (of my first message) and displays message to check email for authentication link. CloudCode service will generate link and send it to users email.
  3. User open his email and click on authentication link.
  4. User redirected on “authentication” page which makes call to the service from step #2 (of my first message), receives user auth-token, sets it to the page session storage and redirects user to the apps main page.
  5. User get’s redirected to the apps main page.

At the moment of redirect user will be fully authenticated.

Regards, Andriy

7

Thank you for the clarification. That is a good idea. I was thinking it would be decentralized but your idea is better.

Thanks,
Tim