Develop Reference

Authentication with google account for native desktop app with backend

I have an application that has both a backend and a frontend (in java). I need to have user authentication but I would prefer not to handle most of it myself. So I thought I could have users authenticate with their google accounts.
The backend part is mostly implemented, and it works fine from the browser:
I try to navigate to a URL of my server, and the browser is redirected to the google login page.
I login, and the browser is redirected back to my server, this time with auth info (some kind of token?) and I get a response.
But I'm having trouble figuring out how to set this up from a desktop app. I would like for the app to have a login button that when pressed, opens the google login page in the system browser for the user to login. If the login is successful, the desktop client can use the info from their google account (e.g. the email address) to identify itself with my server.
It's the first time I'm working on something like this, so I don't know if I'm looking in the right place. My research online leads me to OAuth2.0, but that seems more like authorization than authentication.
I looked at google's OpenID guide and it directed me to using OAuth2 for installed applications, is that the right solution for my use case? Or is that for applications that only have a frontend and all data is kept in the desktop app?

I am not completely sure whether it is secure, and whether it aligns with best practices, but I found a solution. I used the idea of the loopback redirect uri in my own way.
I start an http listener on the desktop app on a random available port, let's say it's port 54321.
I want to contact a url to my server. In that url I add the loopback port as a query argument. So the url would be something like https://myserver.org:8443/signin?loopback_port=54321
I start the system browser with this url. The server requires authentication, so the browser is redirected to google to login and provide authorization for the application to access my google account data.
Once the login in google is done, the browser is redirected back to the url of my server that it was first trying to reach. Now since the authentication is done, the request goes through.
I updated the /signin endpoint on my server to return redirects to /signin2 (again with the loopback_port param). The redirect from /signin will set the JSESSIONID in a cookie in the browser, and when we get the request in /signin2, we can read that JSESSIONID.
When we get the request in /signin2, we use the loopback port and the jsessionid to build a redirect url to the http listener on the desktop app. The jsessionid will be included as a query argument. So the browser is redirected to http://localhost:54321/?JSESSIONID=....
The http listener on the desktop app parses the request to get the JSESSIONID from the cookie, and it can use that in subsequent requests it sends to the server. Having this cookie, the server associates the desktop app's request with the authentication done earlier.

How to implement Java soap client when server uses ADFS authentication?

We are implementing a soap client in Java (using cxf wsdl2java). In previous projects the authentication has been based on either WS-Security or Basic HTTP Authentication. These are both easy to test in SoapUI and implement in java.
This time however, the server uses a Web Application Proxy which works as a reverse proxy, and ADFS (Active Directory Federation Services) for authentication purpose. I don't know the details of what this means, but what happens when opening the wsdl endpoint URL in a browser is that we get redirected to a login page similar to the office login page https://login.microsoftonline.com/ where you have manually click on the account type before entering credentials.
When logging in manually, we get redirected back to the wsdl endpoint with an appended ?authToken=xxx at the end and I think the token lasts for 1 hour. We have tried to ask the provider to use a more standard authentication, but for now this is the only thing we have. How do we approach this?
When trying to do a test request from SoapUI, we just get the complete html code of the login page in response. I see there is a Form Based Authentication option in SoapUI but it won't work since the login page has multiple account types and multiple username/password fields. The workaround for testing is just to login manually and use the authToken. But how can we automate this in the Java cxf client?
When connecting to the endpoint url in a browser, this is how the url looks after redirected to the login page:
[url to adfs seriver]/adfs/ls?version=1.0&action=signin&realm=urn%3AAppProxy%3Acom&appRealm=a10037ed-ca1e-e711-9436-00215a9b01ac&returnUrl=[wsdl endpoint url]&client-request-id=13A5B5A6-B574-0000-6FBA-A51374B5D201

You can't use SOAP to authenticate with ADFS via a login screen. This is because ADFS only supports WS-Fed or SAML-P or OpenID Connect (ADFS 4.0).
What you can do is use WS-Tust to do this.
WS-Fed supports two profile viz. passive (browser login screen) or active (web service / WCF). You need to use the latter.
There are a number of active profile endpoints that are available in ADFS. Not all are enabled by default so you may need to enable them.

HTTP POST Request Popup Window

I am attempting to log into a website using Java's HttpURLConnection. I have figured out how to use a POST request to post to the website and log in, but I have no way of knowing if the login was successful or not.
Looking at some tutorials, I discerned that reloading the page usually works. The problem with this specific implementation is that upon entering credentials, the website opens a pop up window, with the same URL as the parent site.
This can be solved either of two ways. Looking at Chrome's Developer Tools, I realized that the POST request returns whether the login was successful, as seen here
Is it possible to get the popup window or look for the response to the POST request? I'd rather use native java is possible.

Reload will work, if you'll keep the same HTTP session. Actually the website cannot open an popup - the web browser does it according to the login response. You should do the same - that is to check the response. Luckily you don't have to parse the response content, try to check the response code. For login the HTTP 200 may stand for successful login and HTTP 401 for failure.

Google OAUTH: The redirect URI in the request did not match a registered redirect URI

I am trying to make an upload to YouTube from my Java based web app, I spent a few days to understand what and where is the problem and I cannot get it, for now I am pulling my hair out off my head.
I registered my web app in Google Console, so I got a pair of Client ID and Secret and a possibility to download JSON type file with my config.
So here is the config:
{
"web":{
"auth_uri":"https://accounts.google.com/o/oauth2/auth",
"client_secret":"***",
"token_uri":"https://accounts.google.com/o/oauth2/token",
"client_email":"***",
"redirect_uris":["http://localhost:8080/WEBAPP/youtube-callback.html","http://www.WEBAPP.md/youtube-callback.html"],
"client_x509_cert_url":"***",
"client_id":"***",
"auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
"javascript_origins":["http://www.WEBAPP.md/"]
}
}
How is possible that I am getting the default URL from Google?
The redirect URI in the request: http://localhost:8080/Callback did not match a registered redirect URI
It always gives me the default http://localhost:8080/Callback URL instead of mine.
And IDE console shows me that:
Please open the following address in your browser:
https://accounts.google.com/o/oauth2/auth?client_id=***&redirect_uri=http://localhost:8080/Callback&response_type=code&scope=https://www.googleapis.com/auth/youtube.upload
Attempting to open that address in the default browser now...
I am using the last version of dependencies:
google-api-services-youtube v3-rev99-1.17.0-rc and google-api-services-youtubeAnalytics v1-rev35-1.17.0-rc

I think I encountered the same problem as you. I addressed this problem with the following steps：
1) Go to Google Developers Console
2) Set JavaScript origins:
http://localhost
3) Set Redirect URIs:
http://localhost:8080
http://localhost:8080/Callback

When your browser redirects the user to Google's oAuth page, are you passing as a parameter the redirect URI you want Google's server to return to with the token response? Setting a redirect URI in the console is not a way of telling Google where to go when a login attempt comes in, but rather it's a way of telling Google what the allowed redirect URIs are (so if someone else writes a web app with your client ID but a different redirect URI it will be disallowed); your web app should, when someone clicks the "login" button, send the browser to:
https://accounts.google.com/o/oauth2/auth?client_id=XXXXX&redirect_uri=http://localhost:8080/WEBAPP/youtube-callback.html&response_type=code&scope=https://www.googleapis.com/auth/youtube.upload
(the callback URI passed as a parameter must be url-encoded, btw).
When Google's server gets authorization from the user, then, it'll redirect the browser to whatever you sent in as the redirect_uri. It'll include in that request the token as a parameter, so your callback page can then validate the token, get an access token, and move on to the other parts of your app.
If you visit:
http://code.google.com/p/google-api-java-client/wiki/OAuth2#Authorization_Code_Flow
You can see better samples of the java client there, demonstrating that you have to override the getRedirectUri method to specify your callback path so the default isn't used.
The redirect URIs are in the client_secrets.json file for multiple reasons ... one big one is so that the oAuth flow can verify that the redirect your app specifies matches what your app allows.
If you visit https://developers.google.com/api-client-library/java/apis/youtube/v3 You can generate a sample application for yourself that's based directly off your app in the console, in which (again) the getRedirectUri method is overwritten to use your specific callbacks.

I was able to get mine working using the following Client Credentials:
Authorized JavaScript origins
http://localhost
Authorized redirect URIs
http://localhost:8090/oauth2callback
Note: I used port 8090 instead of 8080, but that doesn't matter as long as your python script uses the same port as your client_secret.json file.
Reference: Python Quickstart

You need to go into the developer console and set
http://localhost:8080/WEBAPP/youtube-callback.html
as your callback URL.
This video is slightly outdated, as it shows the older Developer Console instead of the new one, however, the concepts should still apply. You need to find your project in the developer console and register a callback URL.

I thought I had this configured but it turns out I set the URL in the wrong place. I followed the URL provided in the Google error page and added my URL here. Stupid mistake from my part, but easily done. Hope this helps

Spring Security and CAS logout redirecting problem

I need to implement Sign Sign Out in Java using Spring Security. What CAS needs from my application is to access
https://www.home.com/cas/logout.cfm?service=myService&redirect=http://encoded.url.of.my.site
I put this URL to LogoutFilter's constructor parameter (as logoutSuccessUrl), so when I click logout URL on my site, Spring Security clears the session and redirects me to that URL, which is over HTTPS. It does what is supposed to do and the tries to redirect me back to my website's welcome address. However, this address is on HTTP protocol, not on HTTPS. So either because of sending some info in parameters when accessing that secure page, or because of redirecting back to non-secure, Firefox gives me a message:
Although this page is encrypted, the
information you have entered is to be
sent over an unencrypted connection
and could easily be read by a third
party.
OK, this is clear, but... How does logging using SSO work then? It essentially does the same thing. My website redirects to SSO's login page over https, which on success redirects back to my site, which is over plain http. How can I get rid of that message?

OK, after some research I got the answer. Firefox throws this message only if there is some post data in the redirect, which occurs from HTTPS to HTTP. This message can't be disabled, there is a corresponding comment in Firefox'es source code. The data that is posted (in form of XML) should allow to invalidate session. This also gives CAS an ability to invalidate session without any action from the user of the application (CAS posts data to that URL and application invalidates user's session).
Logging in didn't throw any messages because it was a simple redirect, without any data.