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 :)
Related
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.
I am ashamed to admit that I burned four full days trying to get Spring Security 3.1 to play nicely with Google Sign-in in a standard JSF web application. Both are awesome frameworks in their own right but they seemed incompatible. I finally got it to work in some fashion but strongly suspect that I have missed some fundamental concept and am not doing it the best way.
I am writing an app that our helpdesk uses to track system testing during maintenance activities when our systems are down and cannot host the app, so it is hosted externally. Our Active Directory and IdP are down during this activity so I cannot use our normal authentication systems. Google Sign-in is a perfect solution for this.
Google Sign-in works great in the browser using Google Javascript libraries and some simple code. The browser communicates with Google to determine if the user is already signed in, and if not, opens a separate window where the user can submit credentials and authenticate. Then a small bit of Javascript can send a concise, ephemeral id_token returned from Google to the server which the server can use to verify the authentication independently with Google. That part was easy. The beauty is that if the user is already signed into Gmail or some other Google app, authentication has already happened and Google does not challenge the user again.
Spring Security works great on the server side to protect specified resources and authenticate a user with a username and password. However, in this case, we never see the username or password - the credentials are protected by secure communication between the browser and Google. All we know is whether or not the user is authenticated. We can get the Google username, but Spring Security expects credentials that it can use to authenticate, to a database, in-memory user base, or any other system. It is not, to my knowledge, compatible with another system that simply provides yea-or-nay authentication in the browser.
I found many good examples online that use Spring Boot with EnableOAuth2Sso (e.g. here) but surprisingly few that use Spring Security in a standard app server which does not support EnableOAuth2Sso, and those few did not show any solution I could discern.
Here is how I've done it. I followed Google's simple directions here to provide authentication in the browser. I added this code to the onSignIn() method to send the id_token to the server.
var xhr = new XMLHttpRequest(); // Trigger an authentication for Spring security
xhr.open("POST", "/<my app context>/j_spring_security_check", true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
var params = "profileID=" + profile.getId() + "&fullname=" + profile.getName() + "&email=" + profile.getEmail() + "&id_token=" + googleUser.getAuthResponse().id_token
+ "&j_username=" + profile.getEmail() + "&j_password=" + id_token;
xhr.send(params);
window.location.replace("/<my app context>/index.xhtml");
Unfortunately the Spring Authentication object, when passed to the AuthenticationProvider that I provided, did not contain anything but the j_username and j_password parameters as Authentication.getPrincipal() and Authentication.getCredentials(), but this is all I really needed. This is a bit of an abuse of those parameters since I have set them to email and id_token, not username and password.
I wanted to pass the user's full name and email, which Google provides in Javascript as googleUser.getName() and googleUser.getEmail(), to the backend as well. Since Spring Security does not accommodate anything but the username/password, and I was using Primefaces/JSF, I used Primefaces RemoteCommand to call a method on the backing bean with this information. This also feels a little clumsy.
In addition, I had to use window.location.replace() (in code above) because Spring Security did not redirect to my index.xhtml page as expected when I set this in the context with:
<security:form-login login-page='/login.xhtml' authentication-failure-url="/login.xhtml?error=true" default-target-url="/index.html" always-use-default-target="true" />
I have no idea why this does not work.
However, the app does now behave as I want in that it authenticates the user and the authenticated user can access the resources specified in Spring Security, and I wanted to share this in case anyone is doing a similar thing. Can anyone suggest a cleaner/better way? Thanks in advance.
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.
I am developing a REST API, and have found a very interesting problem.
When I access the resources in a web browser (in my case Chrome), everything works fine. However, when I access the resources using a REST client (Google Chrome plugin, web-based client, and a Java applet), NONE of the variables pass to the API. This happens both with GET and POST methods.
I have absolutely no idea why this would be the case, and it's proving very difficult to test the methods before putting them into production (especially with POST methods).
Please help!
At first glance it sounds it could be 2 things:
You are not correctly passing API parameters via your client or
applet
A problem with authentication or cookie management. Does the API require any type of authorization?
Are you forgetting to set a necessary HTTP header?
Do you have control of the API also or is it a third party API? If so, do the params arrive at all or do they arrive empty? What's the error code? - a 403 not authorized (which would make sense if the key doesn't pass) or something else due to missing params.
Try the intermediate step of doing it with CURL form the command line - that'll give you more detail on what's coming back.
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.