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:
Open the Ember app
Redirect to the OAuth provider (login if you haven’t logged in)
Redirect back to Ember app with an access token
Pass the access token to the API of the Ember app
API app gets the user data from the OAuth provider using that token
API returns the user data to the Ember app
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
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?
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.
@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.
Ember app redirects to the OAuth provider
OAuth provider redirects back to the Ember app passing an access token
Ember app stores this token and uses it to authorize its access to the API
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)
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 draft-ietf-oauth-v2-23
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.
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.
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
@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).
@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)
