I would like to build an authentication / authorizaton mobile app that would:
Scenario 1
receive auth requests from web apps when a QR code is scanned
Scenario 2
receive auth requests from web apps when a user tries to login with username
If you know the platform Binance (https://accounts.binance.com/en/login?), you might notice the Scenario 1 I'm describing. As per the second scenario, I would like the user to write its name on an input field and receive a request on a mobile application that is "connected" with the webapp so that the user can willingly authorize oneself by means of a push notification.
Both scenarios require the user to be LOGGED IN in the mobile application, as to prove that they are who they say they are.
As per the technologies I would be using:
nodejs on the backend
react on the frontend
react native / flutter on the mobile
Do you have any resources on the subject?
Thanks
Related
I created an Azure Mobile App Service which is currently accessible 'Anonymously'
Anonymous access is enabled on the App Service app. Users will not be prompted for login.
To make it secure I can enable App Service Authentication which will ask users to log in
But this is not what I want - The data in this app is only accessed by Application without the need of each and every user to login to my app before using it.
So you might say, in this case, Anonymous access is fine but I want to restrict it with something at least like an API Key so I will have access to the API which my app can use to access the data to prevent random requests as anyone can just go and use Postman and start getting data without any authentication.
So in short, I don't want individual user authentication, but at least an API Key to ensure only requests made from my app are authenticated and nothing else.
I am using the following in my mobile app to create a connection and also doing Offline sync etc
MobileServiceClient client = new MobileServiceClient(applicationURL);
Any idea how do I do that?
FYI. My server side backend is in C#
Since you are using Azure Mobile Apps, for your requirement, you could leverage Custom Authentication for building your CustomAuthController to login and generate the JWT token for a specific user without user interaction. The core code snippet for logging would look like as follow:
MobileServiceClient client = new MobileServiceClient("https://{your-mobileapp-name}.azurewebsites.net/");
client.LoginAsync("custom", JObject.FromObject(new{Username="***",Password="***"}));
Note: As the above tutorial mentions as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
And you must explicitly add [Authorize] attribute for your controllers / actions which need to be authorized access. Details you could follow Authentication in the Backend.
I am developing an hybrid mobile app that collects some user info in background while the user is calling (just during a phone call). Then I have an admin dashboard on a website, where the admins can monitor the (almost) real-time status of the mobile users. To do this, my mobile app must send info to the server. Right now I just use:
setInterval(sendData, 5000) to send data each 5sec from the mobile app to the server.
setInterval(refreshData, 5000) to request the current status from the admin dashboard to the server.
I don't need a "strong real-time", so it's enough update each 5secs.
Anyway I'd like to know if it's better use web sockets among the mobile app and the server, since the app should send data very often during the day.
Thank you
I would like to build a very simple Angular 4 app with a WepApi Service as backend.
I would also like to have users register with my app (the basic "create user" - "validate email" - "log in" workflow).
The user/passwords should be stored with my own app (SQL database).
Where would I go for this very basic information? I am highly frustrated with all the "look it's so easy, you can use ANY social media account! Facebook, Twitter, Google, Microsoft! Just three clicks and all is super-secure with OAuth" talk.
Please point me in the right direction - finding this very basic information seems impossible to me.
what i have done is :
Step 1 : call facebook auth from client it returns me id,
profile etc,
Step 2 : then I send fb id to the server (deployed on azure), where it
checks if this fb id already exists in database it redirects to login,
otherwise it creates a new user
you can also authenticate fb token on server side also for more security.
for login with facebook scenario this question might help you.
I would recommend you to use Azure App Service along with Easy Authentication as it allows you to configure your app along with Facebook/Twitter/Google/MSA.
For Starters see this:
How authentication works in App Service
How authorization works in App Service
The following tutorials show how to configure App Service to use different authentication providers:
How to configure your app to use Azure Active Directory login
How to configure your app to use Facebook login
How to configure your app to use Google login
How to configure your app to use Microsoft Account login
How to configure your app to use Twitter login
The above steps do not require you to write any code. However if you need to authorize then you need to handle that in your application.
The above should get you started. Also see this thread where I shared insights on how you can query Facebook: Correct Facebook Graph Api Video Insitghts Request PHP SDK
I also have a blogpost on this here:
Azure App Service: Using Easy Auth to query Facebook information via Graph API
I'd like to implement Google OAuth. I'm a bit confused whether to have it implemented in the client (mobile app) side or the server side!!
Implementing it in the client side would mean shipping the key and secret in the app (which I want to avoid). However, if I do it in the server side, how do I send back the correct response to the client after a successful callback?
Also, what are the benefits of each of the two implementations?
If you're talking about implementing the Google+ OAuth 2 authentication from a native mobile application (not a web view), then, what you need is to create an installed application client and a web application client in the google console. The first one is for your mobile application, and the second one for your server.
Here is the workflow I used for my application :
the mobile application gets the authorization code from google with the g+ sdk, using a scope containing the web application client id. That way, the server has the authorization to connect with google+.
Your scope could look like something like this:
String LOGIN_SCOPES =
"https://www.googleapis.com/auth/plus.login " +
"https://www.googleapis.com/auth/userinfo.email";
String SCOPES = "oauth2:server:client_id:" + GOOGLE_SERVER_CLIENT_ID + ":api_scope:" + LOGIN_SCOPES;
the mobile application calls a server route with the authorization code and the proper redirect uri (the one associated with the installed app in google dev console which usually looks like this 'urn:ietf:wg:oauth:2.0:oob').
the server gets the access token from google with the authorization code, secret id, application id, and the installed application redirect uri (if you use the web application one, it will fail with a redirect_uri_mismatch error).
the server does whatever it wants with the access token, creates a valid session and gives it to the application as a response to its request.
That way, you don't need to store anything on the client side. You still need to send the authorization code from the client to your server (preferably https), but this code can only be used one time and is immediately consumed by the server.
I hope it helps.
Consider the following (common) scenario. I will first try to specify how I understand a (nice) Web API should look like, using OAuth. Please do correct me if I got any of the flows wrong.
My API: the center of attention, all clients use this.
My Web App: Uses the API just like any other client would.
My Mobile App: Also uses the API, the same exact way as the web app. Users should be able to authenticate without opening a browser.
3rd party Web App: Also uses the API - however, the user/resource owner must grant permission for the app to do something. They do this by redirecting to my site (or opening a popup to it), logging the user in if necessary, and prompting the user for access.
3rd party Mobile App: Same requirements as the 3rd party web app.
The Question(s)
Should the API handle authentication and authorization?
How does the API know who (the resource owner that is using the client application), is using the API?
When a user is using my official clients, they should obviously not have to grant any permissions - my clients should have all permissions. How would I distinguish between my official clients, and 3rd party clients when calling the API?
Here is what I understand, and would do so far. This is where I really need help - getting this done right.
Official Web app
- Client attempts to `GET /api/tasks/".
- API says "who are you? (HTTP 401)
- Official web app redirects to login form.
> Bob enters his credentials.
- .. now what? Get an authentication token? Cookie?
Since the web app is just a consumer of my API, how would I manage the logged-in state? Should the web app do that?
Should the web app have direct access to the users database instead of verifying credentials against the API?
I am using .NET (C#) primarily, but I'd love an approach that is applicable to, say, Node JS based API's as well.
How would you go about this? Especially the client flows are a problem for me. The reason I ask, is that I have read that you should not roll your own security solution unless absolutely necessary, so if there are any standard-ish guidelines for this, do let me know. :)
Take a look at the new web API 2 oAuth stuff.
Basically fire up a new web API project and ensure you select to change the authentication.
Then, it's a simple case of calling the register controller. This then creates a token for you which can then be sent in the header of each request for that user.
Check out the API calls using fiddler and create some mock up accounts.
It's been awhile, but I thought I would document what I ended up doing.
I use DotNetOpenAuth. I have a database with clients, and they have a Trusted field - if this is set, it lets the client use the password grant, which automatically grants all scopes that have been predefined for that client.
The 1st-party web app uses plain cookie auth - exposing the client credentials in JS would be too risky.