I have three different apps for which i want to use the same login and profile. Which means if a user updates his profile information or changes his password that has to be updated in all the apps.
Currently im using a single database for all the three apps, but not sure if this is the right way. I checked few sso solutions, but not sure how to make profile table same for all the three apps.
The reason i want profiles table same for all the three apps is because the apps belong to the same industry(healthcare). If a doctor updates his information on one app, that has to be updated in all the three apps so that his information stays same on all the apps.
I'm currently using laravel 5.6 as the backend api and vuejs as the frontend with JWT login
I am late, but thought would help people looking for answers.
1- Using Different API/Service for authentication
As mentioned in the comments it is a good way to create a separate service for authentication. Could create an OAuth server for that purpose.
2 - Using same Database
It can be done is using similar APP_KEY for three applications. It is generally not a recommended way to use same app key for multiple apps, but in this case as three apps works as one and uses same database dont see a much problem with that.
To do so copy the app key from the main application's .env file to other 2 applications .env files. This is because app key is used in the process of encrypting the password when registering the user and logging in. So, it should be similar in all apps for the hashes to match. This way same database and same users table could be used.
Related
I am new to laravel and creating a REST API. The client of the API will be mobile app only. There is no front end view to be shown in browser. I have created the routes and the controllers to handle API requests. Furthermore I deleted the Users table (created by laravel) because I do not need an Web interface etc.
I just want simple token based authentication at this stage ( I am aware there is passport authentication) but I can not even understand that at this stage.
There is only one table in the project.
Candidates
(id (PK), name, phone, details)
mobile app users are candidates also, should I create a token column in this table ? and manually create token at the time of register API and return it back as response ?
Please any simple guide or directions will help, I have search quite a bit online and there seems to be quite a lot many topics that show up such as guards, providers, passport which I am struggling to get.
Thanks,
Elliot.
First of all, you didn’t need to delete the users table. You can use it for api auth too. You just need to create a seperate token table.
However, if you want to implementit manually you need to do a lot of things manually.
This is a huge thing to impelement manually and it's not possible to describe it in a single answer. I will try my best to explain it as simply as I can.
You have to create a authentication system yourself that is for login. Define a middleware to check the authorization of the token sent from client to check the validity of every request (this is the guard part).
Also keep track of the token expiry time. Refreshing the token after each expiry needs to be done too (this is the provider part).
Now there are a lot things inside. Like keeping track of the device the request is coming from, providing different tokens for differenet devices for a single user etc.
If you are into learning how everything works then you can try to build one yourself. But if you plan on deploying it to a professional website, I would suggest try to get accustomed with passport. Reinventing the wheel is really not necessary. I hope it gives you a basic idea. If you have any more questions feel free to comment.
We have a Firebase database connected with an APP which we want to convert to a website now. Laravel is nice frame work but unfortunately unable to sync the existing database to show up on the website as is. End goal is that any changes through an APP should reflect on the website and vice versa. Existing database include the product price, picture, ability for users to message each other , user authentication. In essence it is almost a complete market place.
If you want to use data from the Firebase Realtime Database in a web app/site, consider simply using its JavaScript SDK in your web application.
Doing so allows you app to directly read data from the database, instead of having to set up a web server in Laravel.
To ensure that your users only get access to data they're authorized for, you'll want to use Firebase's security rules. These are enforced on the Firebase server, so once you configure them correctly, there's no way for anyone to bypass them.
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
Initially I would like to inform you that I am using ember 2.10.
Can anyone tell me how to make a login system without a token?
I am developing an offline application with Ember and Electron and I need to make the login system without using external APIs.
If I understand you right, you want to create an application that will support few users. It is possible. You will need to perform following steps:
Install ember-simple-auth plugin. It makes auth-related things much easier
Create custom authenticator that will take a login and password or something from your users and save some identifier in session
Create login and register routes, where users will be able to login or create new credentials
Most probably you will not need an authorizer, because you don't have server api and don't send requests to it
Bear in mind that this will be zero-security system, even if you will use some encryption, because js code is not secured well from exploration. Also bear in mind that electron most probably stores user's data in user's home directory (I can't say for sure as I didn't work with electron, but node-webkit does that). In this case having different windows (or what OS your users will use) users is enough to separate data and you actually don't need any login system.
I have an app that uses parse.com as backend.
If I want to store information about user's in-app purchases in table there, how can I be sure that some guy is not going to create a simple app where users of my app can log (like in my own) in and write in parse-tables whatever they want (for ex.: that they made in-apps when they really didn't). This info is used to give the user access to app's features so it's important that the user really paid for that.
Don't make the table name public knowledge, so don't ever access it directly from the app, always use cloud code. Pass the cloud code some salted hashed details to verify against, and do the verification on save of any new objects being added toot that table with a before save hook. Drop any new objects which don't pass the test.