Can anyone help clarify or provide any guidance on how we can allow our users to maintain a list of authorised devices from where they are allowed to login using Firebase Auth.
Is this a feature of 2fa?
Security is important and we want a user to control and approve logins from specific devices. Does FB Auth capture device information? Can I access this and use it? Do they create a unique fingerprint for each device?
I would like to implement something similar to Google accounts whereby I can revoke access from old devices or devices I dont recognise.
Thanks in advance.
how we can allow our users to maintain a list of authorised devices from where they are allowed to login using Firebase Auth
Firebase Auth doesn't offer this sort of feature.
Security is important and we want a user to control and approve logins from specific devices.
That's something you'll have to provide for yourself somehow.
Does FB Auth capture device information?
No, it doesn't. It allows anyone to call the REST API directly from anywhere that has an internet connection to sign in and get a token.
Related
I get it that Oauth is used to grant permission to a third party application to access a user's data (like photos on his facebook account) without revelaing his facebook credentials to the third party application. For example, when you try to use an online photo editing tool and you want to load a photo from facebook, facebook will pop up a message asking whether you really want to allow the application to access your data. So at that point facebook just returns a temporary access token and the app can use it to access your facebook photos. (as i understand the scope for this access token is such that it only has permission to access the particular user's photos only) Yes, this sort of a setup is required because you can't trust a third party application that much as to give away your credentials.
Assume somehow instead of oauth, facebook used api key authentication. This would mean that all third party applications that have subscribed for facebook API already have a key which they can use to access facebook's data sources.So that the app can directly take you to your facebook photos and facebook will not notify you that an outsider is trying to access your private data. This approach is not suitable for an api that exposes user sensitive data but for apis that expose not so user specific (like google maps) data, the api key approach should be enough, right ?
So my question is, what are the criterion to decide which authentication type should be used ? And appreciate feedback if my understanding is wrong.
Here are 2 of the standard 4 Oauth2 flows which cater for the scenarios you mention.
Authorisation Code
Client Credentials.
Using your Facebook example above you could think of like this:
Use Authorisation Code flow for your "Oauth" scenario, where your app needs delegated authorisation to access a user's Facebook photos. This means the user must login and grant access to your app and your app must have an API key (client ID) issued by Facebook.
Use the client credentials flow for your "API Key" scenario. This would be when your app needs access to, for example, public Facebook pages / info and thus does not require specific user consent and can just use its API Key (Client Id & Client Secret)
I have a question more related to the way OAuth 2 is working but since using IdentityServer to implement OAuth I think it's relevant. I could not find an answer anywhere.
I'm building a website and a mobile app that consumes my own API. Each user of my app will have a username and password, that will give him access to the app/website and though the API to his information.
I'm not sure about the right way to handle the flow for user login:
On the website I have my own designed login form. I don't want to move the user to my auth server to login, and then have him approve the information he gives - he is the user on my system - I have access to all information - kida like facebook has a login and access to the informatio - they don't ask what you're willing to give them. So is implicit really the way for this?
On the mobile app I also have a login form and now I read here (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10) that the OAuth approach is to have the login in a WebView?? Doesn't look like facebook login is in a WebView on their mobile app.
The approach I was first lookin at is the Resource Owner. Users will login, get the token and the refresh token and can start working against my APIs. But storing my client_id and secret on the mobile app? on the website javascript files? doesn't feel right. I can of course make a call to an API that will mask those and be a proxy to the login process... but... (read #4).
In the future I would like to allow access for third-party developers. For them to allow login for users of my system I will use the implicit flow. Also, I plan for those developer accounts to have restricted API access (for example, the number of calls to the API will be limited by plan). What prevents those developers from asking for the username and password of their account on my system on their website, getting the response from my servers with the access token and refresh token, and using my API however they want, without restrictions, and having access to the entire user profile?
Lets say I'm sticking to the resource owner flow, receiving back from the server a token and a refresh token. What should I store on the mobile device and how? What should be stored in the browser and how? the refresh token? and each time he opens the app get a new updated token with that refresh token?
Edit
Just to clarify, because I find a lot of lectures and articles that explain the process from an API consumer point of view (ie. the third-party developer): I am the API owner and the auth server owner, I'm the owner of the user accounts (they are my users of my services), I'm also my own consumer (though the website and the mobile app), and in the future I want to enable third-party developers to allow my users to login with their accounts of my service (kinda like Facebook or Google)
You're correct that you shouldn't store the client_secret in your app, but I doubt you will get around storing the client_id. You could disable the consent screen for your app as well, and build a native login view. You need to store the access_token and the refresh_token on the device (maybe encrypted in a database) if you don't want the user to login everytime they use your app.
As for problem 4, you could do the following:
Embed the client_secret in your (web) app
Set up which hosts have access to your api on the IdentityServer
The IdentityServer generates a salt and sends it to the client
The client calculates a session_secret using hash(ip_address + session_salt)
The client uses the session_secret and the client_secret for the API call
Server validates the hash and client_secret
It's nearly impossible to completely prevent someone from using your API. But you should add various rate limiting methods, such as limiting IP addresses, API calls etc. But nothing will stop someone decompiling your app and accessing your client_id.
Is there a line of code that bypasses the second app authentication screen where you select Allow or Deny? I would like our users to automatically be connected to the registered app.
Thanks!
No, it is not possible to bypass that step. If it were possible it would be a security hole.
Yes, is it possible, for paid networks. To be able to do this, your application should use an access token that must be authorized as verified network admin, so it could impersonate user access tokens, take a look at impersonation on Yammer documentation for more information about this.
How can I use Oauth to provide authentication for my private app?
I understand it's not necessary to make the actual calls, but I want to know about protecting the whole app in a way which my client doesn't need to log in twice.
If this is not possible, how do people manage their private apps?
Question is not clear
but, Here is some info
Oauth is an autherization Flow(Protocol) for end-users to authorize third-party access to their server resources without sharing their credentials(Ie. User Name and or password).
If your app is like third-party app that request user resources(ie. email or other details) from Resource servers(ie. Google , Facebook) Then Oauth is the Fittest solution.
Keep the session cookies (access Token) for avoid log in twice.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.