I'm using phonegap and I want to set up google oauth for mobile and web (e.g. desktop chrome) with the same code. The end result should be an app engine cookie on the client side (whether it is the inapp browser or a desktop browser).
Since I don't want my users to do the consent screen more than once, I need a refresh_token and not just an access_token. (also I've noticed that the cordova webview doesn't have access to cookies like the regular browser)
As I understand, a refresh_token can only be received if you're doing the protocol recommended for web servers, meaning first obtaining the code, then using it to obtain the access_token and refresh_token.
When I'm authenticating in this way, the protocol requires that I send the received code to google to receive the access token, but this is a cross domain request and is blocked on desktop browsers.
How can this be conveniently solved? What is the correct way to achieve the end result?
I crudely solved my problem using my server as a mediator for the cross-domain post requests.
So the flow works like this: I get an authentication code using a pop up window. Then the user enters the code and my javascript sends it to my server. Then the server sends a request for access_token and refresh_token to google, and sends it back to the user.
Seems to work well for now, and not very complicated.
Related
I'm working on a product with two apps: one a single-page web app, and the other a native mobile app. Both make use of the same backend API. Currently the user authenticates using username/password credentials to establish a session cookie. I'm planning on adding support for authentication using OpenID Connect.
For the web app, I'm looking at following the advice for "JavaScript Applications with a Backend" in "OAuth 2.0 for Browser-Based Apps". In that scenario, the authorization code gets sent to the backend, which obtains the ID token and begins a cookie-based session.
I'm trying to work out how this would work on Mobile. The "go to" implementation of OAuth/OIDC on mobile appears to be AppAuth. From what I can see, AppAuth uses a different approach where you end up doing the auth code exchange on the device to get the ID token.
Should I have the mobile app send the ID token on to the backend to prove the user identity (and then begin the session)? Is there any best practice around doing this? Presumably at least the backend would need to validate the JWT and verify the signature?
Alternatively, can AppAuth be used to do a similar flow as done on the web app as mentioned above?
The mobile case does indeed work differently, and is defined in RFC8252, which defines the AppAuth pattern. Both the web and mobile cases have this in common:
Open a system browser at the Authorization Server URL with a Code Flow request URL
Cookies are not used in mobile views, and mobile apps can store tokens securely, unlike browser based apps. The mobile app will send access tokens to APIs, and also make token refresh requests when needed.
Out of interest there are easy to run versions of each in my online code samples, if you want something to compare against. Both flows are tricky to implement though.
I'm implementing login functionality on my site and I'm running into some problems when sending jwt tokens as cookies.
When the user logs in on the frontend, a POST request is sent with "credentials: 'include'" (I'm using fetch) to my backend API, which returns a jwt token if the login was successful. This all works fine, and I can see the cookie in chrome dev tools, and performing actions that require authentication work fine.
However, when I refresh the site, the jwt cookies disappear. I have ruled out errors with expiration. Through experimentation I've figured out that the domain is the problem. The cookie's domain is "127.0.0.1" from the locally hosted instance of the API, which is different than the domain of the locally hosted website. If I manually change the domain of the cookie to the same as the website, the cookie doesn't disappear.
But that does not solve my problem permanently, as the backend API is hosted on a different domain than the frontend. I've been reading up on cross-domain requests but I'm not sure how to proceed from here. I control both the frontend and the backend, but I'm starting to wonder if I might be going about this the wrong way? Would the simplest solution be to host my api on, say 'api.mydomain.com' instead?
I developed a windows mobile application which connects back to my web services hosted on internet to sync with the server data.
I didnt put any control for CSRF on mobile application, Is it required to have a CSRF protection on native applications? If yes why?
** My application is native application not on web browser.
Is it required to have a CSRF protection on native applications?
No, if your mobile application is the only type of consumer (e.g. no web browsers) and your mobile application does not make web requests to other domains then by definition CSRF is not possible as there is no cross site request to counterfeit.
CSRF protection would be on the web server side, not the app, although you can help yourself by setting a cookie from the server on login and adding that cookie to the header of your requests from the native app.
You application will most likely need to be CSRF aware (if you've implemented protections on the backend).
For instance, a general best practice is to supply a token on each request that will be used on the next request to ensure no duplicate requests can be made. Your mobile app will need to be able to get and use this token (again, assuming you've implemented this on the server side).
It really depends upon if your site can be accessed by a human AND/OR the authentication method that you are using for the web site.
If a user can login in any way to this web site that is hosting your web services via a browser then while the user is logged into the site, the answer is yes because CSRF takes advantage of the fact that the browser will send along session and other cookies when the web site is communicated with due to the fact that cookies are automatically added by the browser for all request targeting the same origin regardless of which web site is sending them.
If your web services can be accessed directly via NT Authentication then as long as you are logged into the network, the answer is yes. The reason is because the attacking web site that is using malicious JavaScript is still accessing the web services as YOU regardless of which site is sending the request.
Finally, if there is absolutely no way to login to the site via a browser and you are not using NT Authentication, SilverlightFox's answer is correct. The reason is because there would never be a Session cookie for the site so there is nothing to send when the CSRF attack occurred.
The Fix:
For web, this is fixed via an anti-forgery token, which is sent back with put and post verbs (although you can do it with all verbs). A malicious web site could try to send a request and would certainly pickup your session cookie, but the absence of the anti-forgery token in the put/post causes it to fail.
For mobile, patwhite above suggests a fix, but it would require different web service end points for mobile vs web due to the fact that it is a different strategy for handling the problem.
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.
We're writing a Desktop application that relies on Google Appengine to authenticate the user and retrieve and store data associated to it.
The way we'd like to authenticate the user is that on launching the application the browser is launched at the login url for our application. Then the user logins there, and then the application makes restful calls without any OAUTH object, but re-using the browser session. I'm questioned that this won't work, since we cannot so transparently use the browser session. Is that correct?
Any alternatives beside authenticating from within the app using the ClientLoginApi?
I'm aware of:
How do you access an authenticated Google App Engine service from a (non-web) python client?
The only way to do this is if you can capture the authentication cookie used by the browser, and send it yourself. Obviously, there's no browser- or platform- independent way to do this.
A better option would be to use OAuth, with OAuth for installed apps to obtain the original token.