I am developing a Sinatra web app to which I plan to add a Google sign in capability.
While I am able to understand the Oauth2 authentication mechanism with Google and everything seems to work fine, I have a basic question on maintaining sessions.
I am using the Server side web application flow of Oauth2.
Before I ask my question here is my understanding of the Oauth2 authentication mechanism.
Once the user clicks on the "Sign in with Google" button, the sequence of events are:
The user is redirected to the Google oauth authorization server.
The Google oauth2 authorization server checks if the user has a active
session.
If yes it prompts the user to grant access to my application for the requested data from Google.
If the user grants access then the process of sending back an auth_code and getting access tokens commences.
Based on what I have encountered on the web, the code for all of the above would have to be put in a before filter.
My questions are below:
If I add this code to a before filter, then there would be a round trip to the Google Authentication server for each request that comes to my application from the user.
Am I thinking right in the statement 1 above?
Is this necessary?
Is there some other way of validating session without reaching out to the Google server for each request to my server?
Will this not cause an overhead?
How do web-apps using oauth2 typically handle checking session validity across multiple requests?
Sorry about the longish question and thanks for your patience.
When the user clicks on the Login link and returns with a valid response i.e request.env["omniauth.auth"], you need to store the "uid" in the session and then check for the session in the next requests. Like this
before do
unless ['/login', '/auth/google_oauth2/callback'].include?(action)
unless session[:uid]
redirect "/login"
end
end
end
get "/auth/google_oauth2/callback" do
session[:uid] = request.env["omniauth.auth"]["uid"]
redirect "/"
end
Let me know if it works.
Related
My requirement:
Using google login as the only login method for my website, creating users by google user id, creating authentication sessions after a valid google login.
I saw there was 2 ways to do this:
The standard google docs
(step 1) get id token at frontend https://developers.google.com/identity/sign-in/web/sign-in
(step 2) verify token id at backend https://developers.google.com/identity/sign-in/web/backend-auth
Using spring security OAuth functions
https://dzone.com/articles/getting-started-with-google-sign-in-in-spring-boot
So the problem is,
I just finished implementing measure 1 and found that after the login popup closes the state at frontend is changed. No typical OAuth2 elements like redirect_uri, code and access_token invovled in the process. So is this OAuth at all or is google just packed everything for me so I'm not seeing them?
Is measure 2 better? Because you don't have to deal with, let's say, the leak of id_token and client_id ?
The personas involved are different:
Front end: web OAuth2 flow with user involved. You request an authorization code with a redirect_uri for redirecting the user after the authentication. And then you validate this authorization code against the IDP server (you need a client ID and a client secret).
Back end: implicit OAuth2 flow with secret key file for the authentication, for app authentication. This flow is only to deploy on backend server, you absolutely don't have to share your secret key file in your website front end
EDIT
With your update, I'm not sure to understand. The 3 are equivalent
Pure OAuth flow
Google packaging (the function onSuccess() is called when the authentication is successful in the popup, as you can see in this example
Spring boot packaging.
At the end, the same information are provided and required, the "leak" are the same in all cases. It's simply a packaging preference and habit.
EDIT 2
For getting the access_token or the refresh token, you can simply do this as described here
accessToken = googleUser.reloadAuthResponse().access_token
Then, you can pass it to your backend if you want to perform operations on behalf of the user.
We have a web app in which we allow users to log into the app using any Open ID provider(e.g. Okta, Google, Facebook etc.). We want to implement the correct Open ID Connect prescribed methodology/workflow to keep the user logged into the site.
The existing implementation, looks at the expiry of the Access Token then if it's close to expiry uses a Refresh Token to get a new Access Token to keep the user logged in. I feel like this is wrong. When a user logs in to the web app, the Identity Token is used to Authenticate the identity of the user using the Authorization Code workflow. The Access Token and Refresh Token are stored on the server side. Periodically, the Refresh Token is used to get new Access Tokens to keep the user logged into the site. I believe this is a security risk because -
Imagine if a user is logged onto his OP account in a browser. He opens up Sky and is directly logged into MP because he’s already logged into MP. He then in a separate tab, logs out of his OP account. He will continue to be logged into MP for days on the basis of this Refresh Token/Access Token mechanism! Isn’t this a security risk?
If feel like the correct way to go about this is to use Session Management using iframes as prescribed here on OIDC -
https://openid.net/specs/openid-connect-session-1_0.html
For more context, when a user logs into our WebApp we pull data from the OP's UserInfo endpoint to create a profile within our WebApp and set permissions/roles within our app based on data sent over from the OP's UserInfo endpoint. We continue doing this periodically. For this purpose, I feel like using the Access Token(and using the Refresh Token to get new Access Token) to access the UserInfo API is correct because it conforms to the OAuth 2.0 concept of protecting/authorizing API/Resource endpoints using Access Tokens.
I want to know if this is indeed the correct way to manage how a user should be logged in when supporting Open ID Connect.
I think the first question is whether you want to bind the lifetime of an OpenID Connect provider Single Sign On session with the session of your application. You just want to authenticate a user using their OpenID Connect service. If I logout of Google, I expect to be logged out of GMail, but not a third-party application that used Google for authentication. Would you like to implement Single Sign Out as well?
But if I wanted to be logged out when you logout of the OpenID Connect provider, I would implement the OpenID Connect Session management. There is one thing good to be aware of when using iframes and cookies - browsers have an option to "Block third-party cookies" (that's how Chrome calls it), it's turned off by default, but as far as I know, it disables the SSO functionality when turned on.
I'm not sure why you request the userinfo endpoint periodically. If you just want to check whether the access token is still valid, you could also use the token introspection endpoint.
For security concerns, I would suggest you to read the OAuth 2.0 for Browser-Based Apps RFC. It recommends using the auth code flow with PKCE instead of the implicit flow. With the implicit flow, access tokens transported in redirect URLs stay in network and browser caches and can be used right away by an attacker. The auth code with PKCE needs a code_verifier (one-time secret) in order to be exchanged for tokens. So I would first check how the providers work with a configuration you choose and if it's even supported.
I am trying to implement a OAuth2 Provider, that authenticates users with a custom login.
For understanding I looked at the Spring Boot OAuth2 Tutorial.
I don't quite get, how I can implement my own Authentication meachnism to work with the OAuth2 SSO from my Server.
I want to add custom authentication mechanisms (like "user has to answer a question for authentication" or "user has to enter id and click button for authentication") instead of the Facebook and Github examples.
I read about implementing my own AuthenticationProvider, but I am stuck how to combine all the puzzle parts.
Let's go one step at a time. OAuth is only authz provider so not talk about authentication. Now for your usecase specifically, if you want user to be authenticated then OAuth authz code based flow makes sense (You can even go for implicit flow, check rfc 6749). Now how will this work for you. I am picking up the implicit flow for simplicity, Authz flow is just extension of it where end client gets a temporary code which it exchanges with Identity Server later to get the access token. Here are the steps:
Client App hits the /authorization uri with data as per rfc 6749
After validating the submitted data, server forwards user to Login page (or other page for authentication). After authentication, cookie is set in the browser or data is stored in server to mark a user as authenticated.
After authentication server redirects user to user consent page (You can even skip this if needed depending on need, But OAuth 2 spec contains this) where user specifies which all permissions (scopes) are allowed, here user can allow either allow or deny.
if user allows then these permissions are submitted to server and then server stores the data and redirects the user to client URI with access token in # fragement of client redirect URI (callback URI submitted during actual request)
There are SNS application with 2 servers. Web backend server and REST API server.
The web server allows user login/logout with username/password, and show user information
The REST API server provides APIs like /topics, /comments, it should be stateless without session
The REST API will serve other web applications
There are some potential solutions, but neither is security.
Base Auth, the browser hold the username/password
Token with expiry timestamp, the problem is user could stay on the page until token expires
So, is there a way to protect the REST API when calling it from AJAX?
If I have understood your problem correctly I may suggest you use the Token solution. In order to maintain security you may generate new token on every request (& send it to client in response), which should be used to make next request, and disable token if it is once used or has expired.
Sorry, I meant to mention it as a comment, but I don't have enough reputation.
I have implemented an OAuth2 authentication mechanism in my GWT app. The OAuth2 server is based on Spring framework 3.x (using its Spring security OAuth2 implementation).
I am using the OAuth2 "Authorization code flow" to get the user authenticated (though implicit flow may have been a better choice in our case). So at first, the user is redirected to the OAuth2 server authentication page, he enters his credentials and if he is successfully authenticated, he is redirected back to a url with an oauth code. He will then make a second call to get an access token from the OAuth2 server.
Now, the issue is, we would like the user to be able to bookmark a page in the application and directly access it. If he has already authenticated then he would have direct access to it (no more auth involved). Otherwise, he would have to go into the OAuth2 authentication flow but in the end, should be redirected back to the bookmarked page he intended to access at the beginning.
How can I store this page url and get redirected to it after the user successfully authenticates ?
any help would be appreciated. Thanks!
EDITED
The initial url redirection is done via javascript's document.location.href
The way to maintain the original URI in an OAuth 2.0 Authorization Grant flow is to pass it in the state parameter so that the redirection endpoint can use it, after it exchange the authorization code for an access token, to redirect the user back to that URI.
FYI, this is exactly what Google suggests in the examples in their OAuth 2.0 documentation, e.g. https://developers.google.com/accounts/docs/OAuth2Login
Original answer:
The problem is using the hash part of the URL for the place, which is not sent to the server and thus cannot be used in the redirection to the OAuth2 server authentication page.
You have 2 (maybe 3) solutions:
stop using the hash for the place and switch to HTML5 History; either through gwt-pushstate at the History level, or a custom PlaceHistoryHandler.Historian if you use the Places API. That limits your audience though: http://caniuse.com/history
stop using an HTTP redirect, and instead use JavaScript so you can put the hash in the OAuth2 redirect_uri. So instead of redirecting, send an error page with the appropriate scripts bits.
some browsers append the hash to the URL after a redirection, so your OAuth2 server might be able to pick it (in JavaScript) and append it to the redirect_uri. That might depend on the HTTP status code used for redirecting (from experience, it works with a 301, but you don't want a 301 here). Needs testing.
You can do this using GWT activities and places.