This is something of a follow-up question for Best practice Fetch user's information from the Firebase User UID
there is no admin SDK for my development language. I have found docs on the Firebase Auth REST API. You can get provider info for a particular email address, and you can fetch profile data for a currently-authenticated user by the auth token id, but I don't see a way to retrieve profile data based on the user uid. am i just missing it?
The REST API only provides a public API that is a subset of the client SDKs (e.g. the web SDK). It is not an administrative API, and thus has no documented way to allow looking up a user's by a UID. You should think of it more as an API that allows you to create limited clients on platforms for which no full client SDK is available.
The Fetch providers for email section you linked is there for creating a client that can show the user a list of the provides they might have used to sign in before.
Related
I'm already using the Auth0.js SPA SDK to log my users in. I need to update their profiles on Auth0 and, as far as I understood, this SDK does not support this. I would therefore like to use the auth0.js SDK in the same project, but without asking the user to re-login to get a token for the Management API audience and use it to update their profile.
Any way to do that?
You can obtain Management API token in your SPA. As described here: https://auth0.com/docs/api/management/v2/get-access-tokens-for-spas#available-scopes-and-endpoints
Then, you should be able to update the existing user profile by using any HTTP CLIENT (FETCH API or Request library).
This means that Management API Tokens for SPAs have certain
limitations. Specifically, they are issued in the context of the user
who is currently signed in to Auth0 which limits updates to only the
logged-in user's data. Although this restricts use of the Management
API, it can still be used to perform actions related to updating the
logged-in user's user profile.
I have been reading google+ API and domain API and found out that google+ API are read-only. And domain API is only for domain users. But somehow I just tried buffer, connected my google+ profile and shared some text. It appeared in the posts section. Now my profile was not a part of a domain, it was username#gmail.com. Also, there are other social products which give the same functionality.
How do this work?
Your app can share post on the behalf of the user on Google plus. All you need to do is take the appropriate permission from the user.
https://www.googleapis.com/auth/plus.stream.write Required - Grants
permission for the app to create posts or comments on behalf of a
user. The Google+ Domains API only allows creation of restricted
posts, and only allows comments to be added to restricted posts.
Ref : https://developers.google.com/+/domains/posts/creating
There is an open authentication specification called oAuth that utilizes public api's, for instance: GitHub. Facebook, LinkedIn, Twitter, Google, Slack, etc. I believe the easiest way to implement this strategy is either with a bot, webhook, or my choice api framework Express.
Express has a middleware library called Passport that enables a quick setup of the necessary steps to implement the correct api keys, secrets and callbacks. Essentially what you have to do is create an app with each provider and they will give you the api information necessary for your Passport configuration.
Once you've got that done, then you just hook up a simple router and server, then you've got an app that can allow your users to sign into whichever provider they choose. The beauty behind the solution is their password information is serialized inside a JSON store to prevent security issues.
https://developers.google.com/+/web/api/rest/
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)
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.
I have developed a simple API to allow communication between my Android/iPhone apps and my server. In my application, users need to authenticate themselves and they do it using login/password credentials with the following API call:
http://api.myapp.com/login?user=xxx&pass=pass
Application receives in return:
{ "api_token": "xxxx-xxxx-xxxx-xxxx" }
So basically I exchange my credentials against api_token.
I would like to add Facebook connect support. I have successfully used the Facebook SDK and receives the correct access_token.
However, I need to implement a mechanism to exchange access_token with api_token
Assuming the user has already connected his account with Facebook (on his web user panel), what would be the best implementation to proceed to the exchange?
Here is how I finally did it. It's working very well for more than one year, never had any problem. The idea is to exchange tokens using the following API call:
http://api.myapp.com/login/facebook?access_token=<facebook_access_token>
Server side, you verify validity of the access_token with a simple
wget -qO- https://graph.facebook.com/me?access_token=<facebook_access_token>
Which sends you back a JSON with all user information, including user's Facebook ID. Assuming the user has already connected his account to Facebook, you can lookup the user_id and send back an api_token.
http://developers.facebook.com/docs/authentication/
The best implementation will naturally depend upon your current platform. There are several Ruby on Rails gems, for example, that handle to whole Open Authentication bit for you.