We have a system that supports social logins and we have a feature that users can download api access key and secret key to make APIs programatically.
But when a user account is deleted from social login provider the user can't login in the system. But the same user can access APIs programmatically. Is it possible to stop the API login as well ?
Unfortunately this can't be done, unless the social service supports publishing some kinds of events about deleted users (though I highly doubt that anyone would be doing that). Maybe there is another way to verify for you whether a given account exists in the social service (by calling some endpoint, for example). Then you can periodically check with this endpoint which of users exist. Or call this endpoint when you get a request to the API and verify if the user still exists.
Related
I'd like to implement SSO logins for users in my Firebase web app, but only for users that have an existing account. When I add e.g. the Microsoft provider in Firebase and implement the required UX flows in the web app, anyone with a Microsoft account is able to sign in using that, upon which a new user account is created (if they haven't signed in before). I'd like to restrict this to users that:
have registered previously with e.g. an email and password login method, and
have subsequently chosen to activate the SSO login method in the web app
Is there a recommended way to prevent the default behaviour in Firebase auth for SSO so that I can check for an existing account with the same email and its approved login methods before letting the user log in and/or create a new account?
There is no built-in way to do this in Firebase Authentication, as it makes no distinction between sign-up and sign-in for OAuth users.
The typical approach to implement this is to create a list of the allowed users somewhere that both your app and your server-side logic can find it (like in one of Firebase's databases), and then check against this so-called allowlist in both your client-side and server-side application code (and security rules) after the user signs in and before executing any other application logic for them.
In the application itself, you could show this as "unable to sign in" to the user, since (despite you calling the Firebase API and signing them in there) they have not completed the sign-in into your application itself.
When using OAuth2 against Google (or actually any external provider), how is it possible to verify that the user is still logged in to their Google account on the browser and their user is in good standing?
I don't want disabled users to access the system after they have been disabled, and to make sure that the web app cannot be accessed by anyone using my browser after I logged out of Google without having to delete a bunch of cookies for each site.
Is this even possible?
I explored querying the user ID with the users API but it requires authentication to make the query, and the anonymous API does not work for users without a Google+ account (or at least, not that I could find).
In addition, the users API will not help if the user logged off.
I'm using node.js with express.js and passport.js for authentication, with a cookie session.
Scenario
We are building a new RESTful API for our web application. This API will serve our mobile applications, our web application and authorised customers.
We are using Apigility to build the API and are making use of the OAuth2 implementation it provides.
Currently, our web application relies on a users table, with permissions assigned to each user. These users simply log-in using a web form, and the session is then stored and appropriate permissions checked upon access.
We want to be able to authenticate API access (such as our web app, and authorised customers), so no unauthorised access to the API can happen. However, we also want to authorize the permissions at a user level, therefore some sort of user authentication must also happen as well.
Any authorised access to the API may use a different user, so relying on a single user per client will not work, especially since the permissions are on a per user basis. We also do not want any user to be able to use the API without prior authentication, so wanted to avoid adding every user as a client to OAuth2.
For example:
The web app is authenticated with the API with two users using it:
UserA has user management permissions
UserB does not have user management permissions
Therefore, UserA can POST to /users and receive a 200 OK while UserB should receive a 403 Forbidden.
What we have tried
We have created an example application, and have successfully set up authentication using OAuth2 for the high-level clients and can make calls as expected. But we have not been able to create an authorization model for our users based on this.
We though adding a custom HTTP header with a user token that is provided after an authenticated call to /user/login. But we are not sure if this is the correct method.
The question
How can we both authenticate the high-level clients (such as our web app, or authorised customers) but then authorize access based on the user actually using the system?
You have a few options available to you:
Token-level permissions
You can provide different tokens for each user account, and tie permissions to the token. This runs the risk of the wrong tokens being mixed up with the wrong users. However, this also has the advantage of not having to maintain a user<->token relationship, as the permission is decided at the token level. How you decide which token to generate can be tricky.
User-level permissions
You can tie a user account to a token and that user can then be given read/write permissions. This reduces the risk of a user having a wrong token as they're linked. With this method, you can use the same method of token generation for all user accounts as the token is ignorant of the permission, but does allow them "access" to the API (thus preventing unauthorised access).
I've deliberately avoided mentioning specific types of authentication tokens, as these two concepts can apply to most of the popular choices on the web (token-based, OAuth based).
OAuth has no concept of Identity.
You should look into using OpenID Connect which is a profile on top of Oauth 2.0.
We are trying to integrate TripIt with our web application for itinerary management. I created a new App and got api key & secret. But we want to use the employee's trip it account and retrieve their trips & create trip in their account. Now i have one dilemma, since i am using my api key & secret, i can able to retrieve trips created in my account, but i want to retrieve trips of whoever logged in with their tripit account, with my api key.
So in this scenario, i will ask for user's trip it credentials and is there a way i can get their trips using my api key? Any viable solution is welcome. If you clear me with the flow i can able to understand.
The (OAuth) API key and secret are issued for your application, not for your specific user account. What this means is that your application can be given permission to access the user's data. If you've ever worked with the Twitter or Facebook APIs, TripIt's API behaves much the same.
You register an application through TripIt (sounds like you've already got this step down)
Using an SDK of your choice, you create endpoints in your code to handle the various steps in the OAuth workflow.
Here is a quick rundown of the workflow for OAuth 1.0, which TripIt uses.
The user begins the process of connecting their TripIt account to your application
Your application builds a request token URL and sends the user to TripIt's OAuth dialog, indicating the callback_url
The OAuth dialog (on TripIt's site) prompts the user to accept or decline permissions
If approved, they return to your site (callback_url) with a 'signed' request token as part of the query string
A backend process, typically a simple CURL request, exchanges the request token for an access token to finalize the process
You store the access token associated with the user in your database and use it for future requests against the API
If you happen to be using PHP, here is an open source example application to take a look at. It does not save the token to a database (just keeps it in the session), but you should be able to glean the basic idea from it.
We are developing an SPA - full client base javascript application and need to authenticate our users to get access to the internals.
As I found from the search we can outsource our authentication mechanism and use Google accounts for that. I learned from this site
https://developers.google.com/accounts/docs/OAuth2Login -
How to deal with Google API and mechanism for authentication.
In the short word, we need:
send request to google url with params to ask user to allow SPA use their personal data
in case of success we get a token from Google
we may use this token to get access to API we were asked and work with it.
This is described well and I understand it and have some JS code to make it happen.
What I do not understand.
I have an application with it's private data. I want use user's e-mail as the login, or user id (doesn't matter how to call it) to access app's internals, such as user's created tasks, user's profile, etc. So, to display user's created tasks in my SPA I need query database with the user's e-mail.
I imagine the next scenario:
user click Login with Google button
we obtain an token - this means user was authenticated successfully
we persist user and his e-mail to work with SPA
when user click Logout we clear all access data
Where should I persist this data?
In case of Forms Authentication I understand that we pass login/password to server and if they match the database we create Forms Ticket and store it in cookie.
Is there any similar case with Google's auth? If I'll store user's email in cookie I think that's not very good from security reason. If I'll save a token - I'm not sure why I need it and how to use it in my SPA, I'm not using any Google API after authentication.
Do you have any example case how do we build our process in similar cases?
Thank you.
If all you need is the user's email address, then you would be better off using OpenID instead of OAuth. OAuth provides access to a user's account and services, scoped to a specific resource or set of resources. OpendID is designed just for logging into a third-party service. You can then extract the user's ID and email address from the OpenID login. Note: The ID will always be sent but the email address has to be explicitly requested during authentication.
Google also supports a hybrid OpenID+OAuth scheme that lets you piggyback OAuth requests on top of an OpenID login if there is some resource you need to authenticate to. Take a look at the authentication document to get an idea of how both protocols work and which is better for your scenario.
Once you have the email address returned, you probably shouldn't persist it in a cookie. The normally recommended way to handle it is to add it as a session parameter. That way only the session cookie is stored on the client, and the server can use it find the values it needs. This answer has a good explanation of the differences and when you want to use sessions versus cookies.