Today, Facebook announces its Graph API v2.0 - https://developers.facebook.com/docs/apps/changelog. One permission xmpp_login is no longer available in the new version according to the change log. This permission is critical in order to generate an access token which can be used to authenticate a FB chat client via X-FACEBOOK-PLATFORM SASL mechanism, this is clearly described at FB Chat API https://developers.facebook.com/docs/chat. Any FB App created after 30 April is forced to use v2.0 API, hence cannot request user on xmpp_login permission. Although the old app still has one year time to upgrade, I didn't find any info how to mitigate this missing. Is that meaning FB will deprecate the X-FACEBOOK-PLATFORM SASL for its Chat API?
https://developers.facebook.com/docs/chat have been update now. And yes it is deprecated.
Related
I am building a REST API in node.js which needs to use Flutter and a React web app as their clients. The problem I'm facing is that I'm not sure where to handle the authorization. Both Flutter and React have a prebuilt "UI" from Firebase that doesen't even need to be connected to the backend. But also there is an option to just take the password and email from the forms and send them to my API which sends them to Firebase via a post request. The flow should be this, a user signs up with Firebase and is created, while that is happening he is also being "signed" up on my API so I can append and store data in his account.
I only need Firebase as an authorization layer, I feel that at this point in time I can't build anything comparable in terms of security when it comes to the authorization.
If you want to work with Firebase Authentication accounts on your backend, then you will need to use the Firebase Admin SDK to manage users. In particular, what you need to do is have the client app send the ID token provided by the SDK and verify the token so your backend can do things on the user's behalf.
I would recommend you to avoid implementing integration with Firebase in the client side, and do it only in the server side. You can use Firebase-Admin to integrate with Firebase in your node.js server. Then, the sign up/in request will be via your API.
In this way, your clients don't depend on 3rd party and all of the library updates should be in your server.
I use Passport.js and passport-google-oauth20. which means using Google + API. but I got an email from Google that the Google + API will be shutdown.
UPDATE
from passport.js http://www.passportjs.org/docs/google/
Configuration The Client Id and Client Secret needed to authenticate
with Google can be set up from the Google Developers Console. You may
also need to enable Google+ API in the developer console, otherwise
user profile data may not be fetched. Google supports authentication
with both oAuth 1.0 and oAuth 2.0.
I get a message :
On March 7, 2019, we are shutting down the legacy Google+ APIs. This
has been a progressive shutdown where calls to affected APIs began
intermittently failing on January 28, 2019.
So what should I do? can I no longer use passport.js?
Google is going to shut down Google+ in some time so you wont be able to use Google+ APIs anymore. I dont think you can do much about it. You can remove support of Google+ from you application.
Here is the link - https://www.theverge.com/2018/12/10/18134541/google-plus-privacy-api-data-leak-developers
As per my understanding, you can still use passport-google-oauth2 for google authentication since this is associated with google account not with google+ account.
Your google+ APIs will not work anymore. You can get that information here - https://developers.google.com/+/api-shutdown
Now about your question regarding using passport.js, you should be able to use passport.js but you will not be able to call only google+ APIs. You can use all the other google APIs from using passport.js
When ever you have an issue like this with an opensource project the best course of action is to always check their issue forum.
There is currently an open issue up on passport.js git project 713
If you check the issue there are several ideas for fixes and it includes a pull request for a potential fix using which uses the userinfo endpoint instead of using the Google+ api
fix: handle new userinfo endpoint
I have a REST API, written with express directly. Nowhere in it do I use session, and authentification is for now done using JWT.
However, I dislike having to handle, save and secure user's credentials, that is when I heard about Azure Active Directory.
Adding passport to my app was easy enought, but that's when trouble started.
First, I had to search what strategy I needed, and all of them seems to require the server to maintain sessions/remember who is logged in, all the while using JWT internally. That seems contradictory, JWT is supposed to remove the need of maintaining session.
Finally, I found this MS example which use the Bearer strategy without session.
After setting it up (changing the config file for the right tenant, client ID, changing the routes for a test app more representative of my API), I tried to use them. The protection work well since I am indeed "Unauthorized". But how do I get a valid token to send?
The MSDN guide that use that quickstart don't mention it at all, just redirecting to the AAD library for Android or iOS, implicitely telling me to develop a test app in another language when I just want a crude tool to test if my test server work at all!
That is especially frustrating since I am pretty sure it is "just" a series of HTTP(S) request on the tenant, and the call to the api with the token attached, but I can't find anything to do just that.
/!\: I know asking for something as vague as "How can I do that" isn't a good question, and this question isn't one. What I am asking is why I couldn't find some tools like POSTMan that implement OAuth and allow to quickly test and debug a OAuth protected API. What are the reason that push MSDN to tell me to write a custom tool myself instead of providing a barebone one?
The code sample you mentioned in the post is using the Azure AD V2.0 endpoint. We can use OAuth 2.0 code grant and client credentials flows to acquire the token from this endpoint.
To compose the OAuth 2.0 request directly you can refer the links below:
v2.0 Protocols - OAuth 2.0 Authorization Code Flow
Azure Active Directory v2.0 and the OAuth 2.0 client credentials flow
In addition, the access tokens issued by the v2.0 endpoint can be consumed only by Microsoft Services. Your apps shouldn't need to perform any validation or inspection of access tokens for any of the currently supported scenarios. You can treat access tokens as completely opaque. They are just strings that your app can pass to Microsoft in HTTP requests(refer here).
If you want to protect the custom web API with Azure AD, you can use the Azure AD v1.0 endpoint.
For getting a valid token to send to your API, you'll need to do an auth request to login.microsoftonline.com and get an access token (in the JWT format). Then you can send this token to your api in the http body: "Bearer ey...".
If you want a full sample with a client app that hits that API sample you tried:
Dashboard w/ all the samples for Azure AD Converged Apps
Simple Windows Desktop App
Angular SPA
Node Web API
How to implement native auth with Spotify iOS SDK? I don't want to see popup window of Spotify login as it is currently implemented.
Or is it possible using Web API?
I look at the app called "SoundFocus" on App Store - their Spotify auth screen looks like native - I need to do the same. How to do it?
Thank you
At the moment fully native login is not supported with the SDK:s. SoundFocus is probably using an older API (like libSpotify). You should implement your own backend service (Authorization Code flow) as outlined in the documents here: https://developer.spotify.com/web-api/authorization-guide/
Authorization Code Flow
This method is suitable for long-running applications which the user logs into once. It provides an access token that can be refreshed. Since the token exchange involves sending your secret key, this should happen on a secure location, like a backend service, not from a client like a browser or mobile apps. This flow is described in RFC-6749.
I have a webservice which acts as backend for smartphone apps.
I want to be able to authenticate users as painless as possible, but even though I thought I understood the OAuth I must admit there are some missing pieces here and there.
Authentication:
Let's say the user has an Android phone. He is probably already Authenticated to Google and it would be really nice if I could just extend this authentication to my webservice. Android has OAuth support so the users opens his app, grants permissions to use his google account and the app authenticates him to the web service.
Web service
Since the service should accept users from all kinds of devices it should not be Google specific. It should be possible to register an account and login from any device. I'm unsure if it is possible to register a new account with OAuth alone or if you need some other kind of authentication first - OpenID for instance.
How would the flow be for the generic webservice? A generic API for registering a user and granting him access to an API?
Furthermore - I do not want to control the devices connecting to this service. I can see OAuth requires a consumer_key and a consumer_secret. If I run everything through SSL - is the consumer secret still secret or can I just use some dummy values? Thus avoiding creating a device-registration system where people can acquire a consumer_secret?
For your case, if you want to use Google/Facebook etc as authentication providers, you will need to use the 'Authorization Code' flow of Oauth2. In this case, you register with Google/FB as a developer and get a client id and secret for using their API.
Then you obtain the Login with Google/Facebook button and code, which you will use to fire a "webview" or an embedded browser where the user will be taken to google/facebook and asked to provide his login credentials.
Upon success, an authorization code will be sent to a redirect url that you would have provided while registering as a developer at Google/Facebook. You will need to catch this authorization code and then again call the relevant API to obtain the access token, which you can then use to fetch the user's details to register him in case of first time or authenticate him if he's already registered through this method earlier.