Sonos auth token uses a Code that only works once - sonos

The Code that is returned from the auth endpoint can only be used once to get an access token / refresh token pair. This means it cannot be directly used with Alexa account linking, as that expects to use that code all the time. Any chance we get can a more "permanent" Code?

Sonos employs the Authorization Code flow of OAuth 2.0. In that flow, the auth code returned in the first step is a short-lived, one-time-use code. The Alexa dev site gives a good description of how to use this flow with Alexa skills.
https://developer.amazon.com/blogs/post/Tx3CX1ETRZZ2NPC/Alexa-Account-Linking-5-Steps-to-Seamlessly-Link-Your-Alexa-Skill-with-Login-wit

Related

Malformed mfa_token message when trying to challenge an user with MFA

I am developing an iPhone application to demonstrate the MFA using sms factor with MFA APIs for POC. I am using the authorisation flow for getting my access token (where I get a authorisation code and redeem it for an access token)earlier to MFA implementation. From the documentation, I found out that I need an MFA_token to work with MFA APIs. I added few changes with my existing authorisation process.
I am getting an MFA Token by doing the following steps:
Added scope enroll read:authenticators to authorisation endpoint( i.e. “https://<my_domain>/authorize”)
Added an audience:
https://<my_domain>/mfa to the authorisation endpoint
Then I make a post request to token endpoint with authorization code to get the mfa_token.
The only changes I can observe is now the access token(which I presume to be the mfa_token) is in jwt format with expire time 600 sec. By using this access token(=mfa_token)
I built a custom pages for my user for enrollment and challenging the user via sms.
I am able to enroll user, confirm enrollment using this access token.
But when I challenge an user using this access token I get the following error after https://YOUR_DOMAIN/mfa/challenge call.
{
“error”: “invalid_grant”,
“error_description”: “Malformed mfa_token”
}
Can anyone please say me where I am going wrong?
Is the access token same as the MFA_Token in my case?
Thanks in Advance!
I think the access_token only serves as mfa_token during OOB/device registration. Thenafter, the user will get an mfa_token during auth, which is passed for MFA/OTP challenges
https://auth0.com/docs/login/mfa/ropg-mfa/manage-authenticator-factors-mfa-api#resource-owner-password-grant

Exact online REST API: POST call not working

I am trying to make a post call in Exact Online REST API. I'm trying to create a SalesInvoiceLine. I can perfectly do a GET call via my browser. I am logged in in Exact Online so I don't need authentication since this should be passed via a cookie. I tried POST via a browser. The browser prompts me to login, when I do nothing happens. I've also tried this in Postman:
I am 100% certain these initials are correct, I can login with them in Exact Online. What am I doing wrong?
If this is not the way, how can I post data to Exact Online? There are not that many concrete examples to find online.
You can't log on to the Exact Online REST API with Basic authentication, the mode you are using now.
The web service uses OAuth as authentication mechanism, meaning you have to acquire a token first. The steps to do so are outlined in the official documentation.
It will need some work on your end to register an app, get the flow up and running. Depending on your business needs, you might be helped with one of the apps for Exact Online by the company I work for.
You need to retrieve the CurrentDivision through GET Request https://{Base Uri}/api/v1/current/Me only from OAuth then you need to assign
CurrentDivision to whatever may be the API call .../api/v1/{CurrentDivision}/../....
Without authorization by Auth 2.0, neither is impossible.
To authorize the ExactOnline API calls you have to do the following:
Register the app in the developer portal. Bear in mind that you have to do a separate registration for French, UK or Dutch version of ExactOnline (this is indeed a pain).
In case you want your application to be used by other accounts than yours, you have to submit the app for validation, this usually takes 2-3 weeks.
EO uses standard OAuth 2.0 schema (very similar to what Google is using with their services). You have to use endpoint GET /api/oauth2/auth for building an authorization link and endpoint POST /api/oauth2/token for obtaining both access and refresh tokens.
Please bear in mind that many Auth 2.0 services are proving long-lasting refresh token. This is not the case of EO. The refresh token is invalidated every time when the access token is requested (endpoint POST /api/oauth2/token). With access token new refresh token is supplied, so make sure you update you refresh token as well.
The access token is placed in HTTP header as "Authorization: Bearer {{ACCESS_TOKEN}}"
In case you want to automate the EO API calls and do not want to code anything on your own, you can try one of the pre-build Exact Online API connectors, created by the company I work for.

Generate Permanent Instagram Access Token

We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)

Non-Flask Frontend with Flask Backend Confusion

all,
I need a little bit of guidance here. I have a Polymer frontend that handles Google oAuth to allow the user in the app. The front end captures the user's email address from oAuth and uses that for GET requests to a Flask API that I built on the backend. I did not build authentication into my Flask API because I didn't think I needed to since I have Polymer as the gatekeeper. I realized though that folks can see the source code and retried the API URL to use if they wanted to capture other user's data.
I am looking for guidance on how I can lock down the API backend given I am only using Google oAuth on the front end.
Thank you,
Marcos
I am not sure if this is the correct answer, but I will post my result anyway. If wrong, send feedback. I am going to have my frontend send the user's access token from the auth process in the header with every API call. My backend API will take that access token and use it to query the Google API to find what email address the token was created by. If the email matches the email the API call is requesting data for, data will be returned. If not, it will return an error.

Does Google+ JavaScript API have an equivalent to Facebook's signed_request?

The Google+ Sign-In button bears a striking similarity to the Facebook Login API, and I like that.
The Facebook JS SDK has a signed_request parameter that's provided on the client side but which can be passed to my server, verifying that client-side authentication has taken place. It's cryptographically signed by Facebook, which allows me to verify that the client is logged in without talking to the Facebook on the server side.
Is there a way to do something similar with the G+ JS API? Specifically, I want to do client-side authentication, then POST some data to my server and verify that the client really is logged in to Google, without initiating a server-side request to Google.
(I want this because I only want to use the sign in button as a registration mechanism; I don't want to post to Google Plus or get the user's list of friends or anything like that, which would normally require a full access token.)
Google+ does not make requests to your application on the user's behalf at this time, outside of a callback URL set as part of a vanilla OAuth 2.0 flow.
When receiving a new token or authorization code, you should make the tokeninfo request server-side in order to verify that the token you've received is legitimate, and for the intended user.
I'm not sure which platform your server is using, so I can't paste the relevant code, but please see here for a code sample.
So, actually there is a pretty good match for that parameter, the id_token that is returned along with the access_token. It's a signed json web token that includes a userid, the client ID and so on. It sounds like this would address your use case! Take a look at http://android-developers.blogspot.nl/2013/01/verifying-back-end-calls-from-android.html this blog post by Tim Bray - it's Android focused, but the same logic pretty much works for any client.
Once you get this, you know its valid at the point of delivery, just liked a signed_request. Of course in either case if the user signs out or revokes access to your app the access token may no longer be valid for making calls.