Spotify Connect supports onboarding a device (i.e. wifi speaker) into your account directly from your Spotify Application. This is done through a protocol called informally zeroconf. It has been reversed engineered and documented to some extend.
Sadly, all the documentation on the internet explains how to implement your own Spotify Connect device.
I'm searching for the other side: How can I onboard a Spotify Connect device into my account. I have an OAuth2 Token.
I already gathered some information
The Spotify Connect Device announces an HTTP endpoint via MDNS
On this http endpoint, you do a POST to the announced endpoint, providing action=addUser and various more parameters as form encoded payload:
#!/bin/bash
USERNAME="theomega86"
TOKEN="BQBfYx[REDACTED]kMqbtlg"
curl -v -X POST -d "action=addUser&userName=$USERNAME&tokenType=accesstoken&blob=$TOKEN&clientKey=&loginId=x&deviceName=x&deviceId=x&version=2.7.1" http://192.168.1.102:51368/0
I was able to retrieve the appropriate values by capturing the packages the Spotify client is sending to the Spotify connect device. The only interesting payload in this request is the blob parameter. While this is a good step forward, the provided blob runs out after one hour. Sadly this blob is not a normal OAUTH2 token (I tried providing that). Does anyone have an idea how to construct the blob payload, assuming that I have an oauth2 token ready?
Related
I'm building a mobile app (and possibly a website) that uses a REST API to handle all the logic.
That being said, the REST api itself should call a 3rd party REST API (the Spotify one) to handle the logic for the app/website.
So basically the user should sign in to my app/website using its Spotify account and my API should make calls to the Spotify Web Api to retrieve user data using its access token, and then send them back to the app/website.
Now I've spent quite some time studying Spotify guidelines about authentication here and it looks like the Authorization Code Flow should fit my use case.
I definitely need to call the /authorize endpoint to retrieve the code from my app since I need user interaction for that. After that, I do get back the **code** that I should exchange for an access_token and refresh_token.
But as I said, it's not the app itself the makes the calls to the Spotify API, but my API. So theoretically I should send the received code to my API and let him handled retrieving and refreshing the access_token and refresh_token.
So my question is if this makes sense? Is it ok to send the code from the app to my api?
Not sure if it's clear so I'll attach a diagram of what I'm intending of doing.
Also probably after receiving the code, I would send back my own token to the app to be used with each future request (somehow similar with what you would do when you handle authorization with Facebook or other socials)
Hmm - some assumptions below, but I would aim to use standard flows. Some solutions are not possible in a good way though.
BUSINESS SOLUTION
Are you trying to build an app that combines the user's Spotify data with your own data for the user?
ARCHITECTURE TO AIM FOR
Your own UIs and APIs should use tokens issued by you and not Spotify. Only use Spotify tokens when you need to access Spotify resources. This leads to simple and reliable code.
STANDARD OPTION 1
This is based on you being in control of data from multiple sources:
You should have your own login and token issuing system. UI first logs into your app, which enables it to call your API with a token.
When you want to access Spotify you need to redirect the user again. The user can then consent to you using Spotify resources in your app, after which your web / mobile UIs get a Spotify token and can call Spotify APIs.
STANDARD OPTION 2
This is based on allowing the user to sign in with a familiar credential, which works via a federated login:
User needs to login
Your app redirects to your Authorization Server
There is a second redirect to Spotify
User logs in at Spotify
Spotify posts a token to your Authorization Server
Your Authorization Server posts its own token to your mobile app
Meanwhile your Web API has its own connection to Spotify that uses the Client Credentials Flow.
DOUBLE HOPPING CODES / TOKENS
This is not insecure, but it will add a lot of complexity and is not standard. You would need to maintain some kind of API session with 2 types of token per user and access token expiry would be a horrible area.
MOBILE FLOW
For mobile apps you should use Authorization Code Flow (PKCE) - my blog posts have some stuff on messages and user experience.
I hope to build a mobile app that sends credit card information to an aws-lambda microservice, which then submits that information to stripe. I'm concerned about PCI compliance/security, and I'm wondering if there is something I'm missing. The following is my plan:
1) Users sign in using PCI compliant passwords - and are assigned unique ids and get cognito access keys.
2) Users enter payment information in the mobile app. The app then sends that credit card data via POST request using HTTPS to a cognito authenticated aws-lambda instance (api gateway is used to create endpoints).
3) Upon a successful post request the app deletes the local credit card data.
4) The lambda instance decrypts encrypted stripe secret access keys using KMS.
5) The lambda instance uses Stripe NodeJS sdk to send the data to stripe and stores stripe tokens in databases.
6) At no point does the Lambda instance save ANY credit card data - it ONLY writes Stripe tokens to the database.
Is there anything I'm missing here? Is there something I should be concerned about?
EDIT:
Additional Info:
Credit card details are collected within the app and stored in the app state until they are deleted. The https POST does not use Stripe tools because I'm using React Native.
Further to our discussion in the comments, you could write a service wrapper to POST the data directly to Stripe using their JavaScript API. You'd just need to embed the public API key in your app.
See the solution in this blog post: http://blog.bigbinary.com/2015/11/03/using-stripe-api-in-react-native-with-fetch.html
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
I've successfully completed account linking on api.ai, and now I'm trying to execute a webhook. The problem here is that I need the token that was generated during the linking process to go into the authentication field. Otherwise I will always get a "403" error back. How can you change the auth token in the webhook header field dynamically for each user that issues a Google Home voice command?
For all I know that's not currently possible. I pretty much had the same issue, and I resorted to connecting to an intermediate server that handles the webhook, extracts the access token (available via the actions-on-google node.js API as getUser().access_token), and then forwards the request in the right format to the original host.
I'm working on a project to connect Google Apps (Contacts, Gmail, etc.) to our own private software.
I'd like to use Hapi.js in order to achieve this, but since I have no expertise in the matter (OAuth, Google, etc) I found it to be quite challenging.
I wonder if it's posible to use Hapijs and Bell to handle the "ask permission" flow, and once authorized save the credentials to long-term uses.
Also, is it possible to use Bell to handle token refresh and consume api? (like requesting http://www.google.com/m8/feeds/contacts/default/full)
In the documentation for Bell, there's an example for twitter, basically you need to change the provider to Google: https://www.npmjs.com/package/bell
When you request access, you can add the parameter access_type with a value of offline. The server will response also with a refresh token that you can use in further requests to the API's without asking for the user credentials again.
You won't be able to store the actual user's credentials since it wouldn't be secure.
You can use the Google OAuth playground to learn more about the authentication process, here is the link https://developers.google.com/oauthplayground/
Here you can find more information and examples of using node.js and the Google API's