I'm developing for Android and currently use facebook-android-sdk for authentication.
From what I can see there is no use of the app secret in that code which is great.
Now that Facebook are going to remove the offline_access permission I need to extend the access token. Unfortunately the sdk's extendAccessToken method isn't stand alone and requires the official Facebook application to be installed which is unacceptable for me.
So I decided to implement extendAccessToken directly (similar to the iphone sdk implementation).
The problem is the HTTP request for extending an access token requires the client_secret field which means I need to put the app secret in the code itself. This doesn't feel safe at all for an Android/Java application that can be reverse engineered easily.
Are there any alternatives?
Why not host the code for doing this on your own server, and have the client extend the token via a call to your server?
So here's what I've discovered so far about Android/iOS sdks in regards to generating/extending tokens.
I've found 2 methods to generate the tokens client side with the SDK's and 3 methods to extend the tokens.
Generating:
1) Facebook app. Produces a SSO token
2) Web browser(iOS)/web dialog(Android/BB). Produces a SSO token on iOS and non-SSO token on Android/BB
These tokens are all long term tokens.
Extending:
1) iOS/Android app. In the Android case only if the user is signed into the app, otherwise the call to the bound service never returns anything, not even an error. Haven't tested iOS for that scenario.
2) auth.extendSSOAccessToken. This is the endpoint for the old API which, as far as I can tell, the iOS SDK still uses if the official app isn't present. Now if you use this endpoint on a token that wasn't generated with SSO (Android popup dialog) you get an error code 10 with a msg telling you the token wasn't generated with SSO. This might lead you to suspect that it could work as long as your token was generated via SSO. Your suspicion would be wrong, it gives you an error code 100 with a msg of "Access token for the Facebook application not supplied". This leaves this method completely useless on Android as far as I can tell.
3) oauth/access_token. This is the endpoint that FB tells us to use in their roadmap. Of course this method a) exposes your APP_SECRET (which FB strongly suggests not to) via apk decompilation/unpackaging and b) only works for extending short term tokens into long term tokens. So if you're starting off with a long term token, which is the default returned when on Android/iOS, you need to generate a short term token first and then extend it with this method client side (unsafe) or server side (not for everyone). How do you generate a short term token from a long term token? Wish I knew =(.
So far haven't been able find any ideas for accomplishing this anywhere. If anyone does know, Please Share!
This would at least give the people with servers a safe method for extending long term tokens.
Related
For the first time, we are developing a new project that needs to support the browser (a website) and a mobile app built on react-native.
We have plenty of experience developing for the web, but little to no experience in the mobile app world.
We are now defining our API and trying to make it work for both platforms - This will be a basic JSON API, running on Flask. The API will have some public endpoints, and some protected ones as well (that require auth). We want a cross platform auth solution.
Typically, for the web, we have always relied on cookie based sessions (encrypted) that frameworks like Flask provide. We have been successfully using these in various scenarios: loading HTML templates directly from the web framework, or even when the frontend application runs on React (same domain + HttpOnly + secure cookies).
The introduction of react-native could potentially bring some new challenges, and some of our developers worry about not being able to continue to use our typical session based cookies - They are advocating to using something like JWT for authorization, for both the browser and app (and yes, I know that we can't compare sessions to token based auth).
I'm not a big fan of token based authorization (for a number of reasons, could entertain that conversation if anyone wants to waste some time...), and I can't seem to understand why we shouldn't stick to our normal encrypted "Cookie" value.
Here is how I imagine this could work, based on using the Flask cookie session:
A user hits /api/login with some credentials
The endpoint will validate the user and return back whatever response + the Set-Cookie header with a value of session=<encrypted string>
Any further requests from the browser/app would send back the cookie value again.
Essentially, nothing would change for typical browser implementations, this is how browsers work by default.
The react-native documentation mentions a few issues with cookie based authentication: https://reactnative.dev/docs/network#known-issues-with-fetch-and-cookie-based-authentication
From what I can gather (my knowledge is extremely limited on this subject), react-native might not always respect the Set-Cookie header. Which is OK - we would just have to make sure to send back the expected header with any further requests.
This, in theory, would fulfil our requirements.
I'm looking for feedback on my "solution", am I missing anything? Did I get HTTP completely wrong?
React Native actually provides networking similar to that of websites developed with basic JavaScript, which also supports cookie based authentication, however there are some serious caveats as mentioned in here
The following options are currently not working with fetch
redirect:manual
credentials:omit
Having same name headers on Android will result in only the latest one being present. A temporary solution can be found here:
https://github.com/facebook/react-native/issues/18837#issuecomment-398779994.
Cookie based authentication is currently unstable. You can view some of the issues raised here:
https://github.com/facebook/react-native/issues/23185
As a minimum on iOS, when redirected through a 302, if a Set-Cookie header is present, the cookie is not set properly. Since the redirect
cannot be handled manually this might cause a scenario where infinite
requests occur if the redirect is the result of an expired session.
Therefore, I would advise against using it as it is unstable and might give you a hard time dealing with it
I also suggest looking into frameworks that handle authentication for you, such as auth0
Hope you find this helpful :)
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.
There seem to be no complete explanations of how to do this, or even enough fragments for me to piece together what I have to do. After about 16 hours of studying, I am at wit's end.
It seems like I can't use SSO, and I also can't use PKCE because there is no working example anywhere on the web. There is a github repo with an example implementation, but it does not function and after 2 hours playing with it I cannot determine what I need to do to move forward this way.
Thanks for any help.
You can add offline_access to your scope (e.g. "scope": "offline_access openid something:else",) and this will yield you a refresh_token.
Auth0 currently supports unlimited refresh_token usage, so when your access_token expires (you either can track expiration time manually using "expires_in": 86400 value in respones or react on 401 response from api) - you can send your refresh token to OAuth2 api endpoint and receive new access token back. They have few descent articles about this matter and what you need to configure for your clients and API as well as what not to do (depending on your client security assumptions).
Take a note - you must secure refresh_token properly - store it in some reliable store and prevent any external scripts from accessing it. I assume with electron app you can do it more reliable than with a public website.
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.
I'm trying to write a new application using the Flattr REST-API version 1 (not the beta v2). The application acquires a request token at first, which seems to work properly. But I run into a problem authenticating the user. The link created for authentication looks like this:
https://api.flattr.com/oauth/authenticate?access_scope=read,click&oauth_token=MY_REQUEST_TOKEN
Clicking the link everything seems alright. Information about the application and the scope requested is shown, but clicking "Authenticate", there's no pin code, but the following error from https://flattr.com/apps/pincode/MY_REQUEST_TOKEN:
Something went wrong. Please try again
BUT now the Application IS in the authorized application list of the user though that doesn't really help if the user can't get the pin code...
The Application type is set to client. It's the first time I try to work with the API so I'm not sure if I miss anything important? Would be grateful for some help.
Just as an update: We finally changed to API v2. Getting Authorization for our application feels a bit clumsy, as we set the redirecturi to some webpage, where we display the returned code and let the user copy&paste it into our client application... we kind of made our own pincode-flow :/
If possible, please use the v2 api, which uses oauth2 + bearer token.
However, the new API doesn't support authentication using the pincode flow.
As stated by Maike this is probably a bug that has surfaced yet again :(
I'll create an internal bug ticket and try to get it fixed.
The pincode isn't a feature planned. You can use the oauth2 "implicit grant" to authenticate the resources owner. This isn't documented at the moment but is possible.
When you do the request to https://flattr.com/oauth/authorize you pass the response_type token instead of code. This will append a access_token fragment in your callback URL. In your http client it might be possible to catch the 302 from our server and parse the access_token from the fragment.
All this requires a http client in your application whom you can control the flow inside your app.