Authentication flow with Ember and a custom OAuth2.0 provider


#1

Hello guys,

I am about start a new project and I want to separate it into small apps, which will have a separate Ember app and an API. The thing is that I don’t want the user signing into those apps one by one. That’s why I am planning to create a custom OAuth2.0 provider, which will be used to centralize the user logins (is there a better way?).

I am not sure about the flow of the process though. My current idea is as follows:

  1. Open the Ember app
  2. Redirect to the OAuth provider (login if you haven’t logged in)
  3. Redirect back to Ember app with an access token
  4. Pass the access token to the API of the Ember app
  5. API app gets the user data from the OAuth provider using that token
  6. API returns the user data to the Ember app
  7. If everything is ok, I create a new session in the Ember app

Couple of questions arise from this approach

  • Do I need to use the token and get the user from the OAuth provider on every single request to the API?
  • Or I just store the user data in the API?

Do you think that this flow is good or maybe you would use a different one? Any suggestions are welcomed :slight_smile:


#2

check out


#3

Hey varblob. I am interested in the flow of the authentication. Torii and Simple Auth are great addons, but I would like to have a full control on how to implement it.

To put it in few words, how would you authenticate an API using a custom OAuth provider?


#4

Whilst I may have suggestions I haven’t spent nearly as much time thinking about the problem as compared to these addons. Torii does oath if you want to roll your own oath it would probably be a good idea to look though their source code and see how they solved the problem of oauth.


#5

I’m thinking about something similar. Do you have multiple APIs or do all Ember apps point to a central API?


#6

@varblob Torii provides really nice wrapper for OAuth providers like Facebook, G+, etc which ask you for permission in a popup window. But I don’t really need this. In the system I am working, the users will be managed in the provider and all applications using it will be authorized (so there is no need for the user to authorize the app manually), that’s why a redirect feels like the better solution.

@gordon_c I will have multiple API. They will go in pairs with an Ember app, so every one of them will have a separate API.

I think I will go with the following approach.

  1. Ember app redirects to the OAuth provider
  2. OAuth provider redirects back to the Ember app passing an access token
  3. Ember app stores this token and uses it to authorize its access to the API
  4. When a request is made to the API, it checks to see if there is a user with that token
    • If there is no user - a request is made to the OAuth provider to get the user
    • The users get saved (or if there is a user with the same id, the record gets updated)
  5. A user object is passed to the Ember app
  6. Login success

What do you think guys?


#7

What about doing the redirect stuff in an iframe instead of a popup. If you’re only using it with your own app you don’t really have to worry about click jacking http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.13

If you use an iframe I believe you can use torii. From my understanding the only reason torii can’t do a full redirect is because at it’s core is a promise.


#8

Are you sure that you have the need for multiple apps? Our main product combines 6 seperate services with 7 internal API’s and we use pods to differentiate our services.

Just wanted to make sure you were heading down the correct road.


#9

@david_duncan when you say using pods to differentiate services what do you mean by that?


#10

RE: Varblob -

We have one unified interface that is logged into, but then the user can select their service and proceed to that individual service.

All the code is separated into pods, and each pod has its own base adapter that calls a different API.

I guess my question really was - how different are these individual apps that they truly need to be split up? Do they share the same user/account models? If so they can probably share the same ember app, even if they have radically different interfaces


#11

@david_duncan I don’t think that this will work in our case because users will have access to different apps. I don’t think it’s a good idea to send them one big file with all the logic inside.

But then when you think about it, probably the biggest file will be the vendors files and most probably it will be the same (depending on the addons).


#12

@mupkoo - We do have it the same way. we have tiered apps and we have different access to apps based on subscription

Just trying to make sure the request for solution in this thread was the correct path for you. It might be that you need completely seperate apps (And you might benefit from separating them)


#13

@mupkoo you may also want to keep an eye on engines


#14

How does engines relate to this? I thought it was an “areas” type feature?