I have developed a Spring server that serves an Android app where
users can sign up via email or via Google. Sign up in this case is performed via grant type password / google.
Now, I am planning to let my server act as a OAuth2 provider where users can connect external clients and hand access tokens to them via authorization_code grant type allowing these clients to access certain REST API endpoints on my server.
The basic flow is like this:
On the external client, the user initiates a call to /oauth/authorize endpoint with parameters
response_type : code
client_id : id_of_client
redirect_uri : uri_where_external_client_can_receive_auth_code
custom design login page is shown, user enters username and password
after successful login, user is presented with the "confirm access" page (/oauth/confirm_access) and grants access to the client
after confirmation, the redirect uri is called with a code parameter usable for getting tokens
external client calls the /oauth/token end point with parameters
grant_type : authorization_code
code : auth_code_that_was_previously_returned
client_id : id_of_client
redirect_uri : ...
upon success, access & refresh token are returned
I have already implemented this flow, and it works.
Now I want to ramp things up a little bit and enhance my custom login page with the ability that users can not only authenticate via username and password to connect external clients, but also via Google.
The problem is that my login form currently looks like this (custom_login.jsp):
<html>
<head>
<title>Login</title>
</head>
<body>
<form action="/login" method="post">
<div class="form-group">
<label for="username">Username:</label> <input type="text"
class="form-control" id="username" name="username">
</div>
<div class="form-group">
<label for="password">Password:</label> <input type="password"
class="form-control" id="password" name="password">
</div>
<button type="submit" class="btn btn-success">Login</button>
<input type="hidden" name="${_csrf.parameterName}"
value="${_csrf.token}" />
</form>
</body>
</html>
As you can see, submitting the login form makes a POST request to the /login endpoint of my server which is out of my control and redirects to the /oauth/confirm_access endpoint.
If I want to support Google sign in I would have to add a Google sign in button to my custom_login.jsp and then I am pretty much stuck. I have no idea how I can validate the user that signed in with Google with my server like the /login endpoint does with username and password and then further redirect to /oauth/confirm_access endpoint. Does anyone know how to do that?
Related
I am trying to request an access token from Google do I can access a Google Drive account, to upload files.
I can make a an Auth request ...
<form method="POST" action="https://accounts.google.com/o/oauth2/auth">
<input type="hidden" name="scope" value="[YOUR SCOPE]"/>
<input type="hidden" name="client_id" value="[YOUR CLIENT ID]"/>
<input type="hidden" name="response_type" value="code"/>
<input type="hidden" name="redirect_uri" value="[YOUR RETURN URL]"/>
<input type="hidden" name="access_type" value="offline"/>
<input type="submit"/>
</form>
Why do I need the redirect_uri if I am making an HTTP request to obtain the access token. Wouldn't the token be returned within the response body?
My app does not involve any user interaction so I am not sure why a redirect is even necessary. I don't wish to use an SDK or library, rather I would just like to use HTTP via Postman.
My app does not involve any user interaction
Oauth2 does require user interaction to authenticate to a users account then your going to have to request access from them. A consent screen is displayed and the code is returned to the redirect uri
back to the basics of form submit ( without javascript), the form data will be sent to the uri you set in the action and the page will be redirected to what the server set it to, or page gets "reloaded" with a page that shows the response od the server.
I never tried Google OAuth2, but in general for this case, usually if your form submit is successful, it will redirect to your redirect_uri with the token appended on the uri as hash.
just realized u are using code grant type. so the flow is after this form submit, it will get redirected to Google IDM to authenticate and accpt consent, then redirect to redirect_uri with the auth code appended. then u can get the token by requesting it from the token endpoint with the code you obtained.
Using Laravel 5.5, and Laravel's built-in authentication system.
Confused about the Remember me option, this is my remember view
<div class="col-xs-6">
<div class="checkbox checkbox-primary" style="margin: 0;">
<input id="checkbox-remember" type="checkbox" name="remember" {{ old('remember') ? 'checked' : '' }}>
<label for="checkbox-remember">Remember me</label>
</div>
</div>
When checked, it does add the remember_token token in the User database, so that part works. But it doesn't seem to 'remember' anything? All users whether they have a remember_me token or not can access the website straight away if they close the website/open it again. All users need to re-enter their email/password if they sign out and the remember-me box is not checked whether they have the remember_me token or not.
Tried both the file and the cookie session driver.
Struggling to see what exactly does it remember?
The remember me functionality from Laravel provides an automatic login for users who signed in with the remember me checkbox checked. This way users who closed their browser or killed their session don't have to login again.
Contrary to other websites (or some browsers, for that matter) who remember the credentials and put them in the login for you, Laravel doesn't do that.
As Laravel states in it's documentation:
If you would like to provide "remember me" functionality in your application, you may pass a boolean value as the second argument to the attempt method, which will keep the user authenticated indefinitely, or until they manually logout.
I've tried to add Spring Security into my app but I don't seem able to make the log out work.
In my springcontext.xml I have:
<logout logout-success-url="/login.xhtml" invalidate-session="true" delete-cookies="JSESSIONID"/>
and I try to log out using:
<p>Logout</p>
OR
<form action="APP/j_spring_security_logout" method="POST">
<input type="submit" value="LOG OUT"/>
</form>
In both cases I get redirected to login.xhtml but when I try to go back to restricted pages that should be filtered I can access it without problem and the user is still logged in.
I am trying to implement Google Oauth2 with Spring Social and spring-social-google. Initial authentication works fine. However after some time the authentication expires and I am hit by
org.springframework.social.ExpiredAuthorizationException: The authorization has expired.
How can you recover from this exception? Is it possible to somehow refresh the authorization?
Try to send additional access_type=offline paramter during authorization. It may looks something like this:
<form ...>
.....
<input type="hidden" name="access_type" value="offline"/>
</form>
Normally in this case authorization will be refreshed automatically for you. See this entry for more details.
If I have this page in "http://example.com/login" with GET verb:
<form action="https://example.com/login" method="post">
<input type="text" name="login"/>
<input type="password" name="pass"/>
<input type="submit" value="Login"/>
</form>
Is it a security flaw? I mean, the page is HTTP but when sending the data it uses HTTPS. I have read several times that I should require HTTPS already in the login page, but I don't clearly see why.
Yes, it's flawed. What you have is secure as far as it goes, as long as it's your login form the user is seeing.
Because your login form isn't secured, I can come along and substitute my own spoof login form and collect your users' login details, eg. via a man-in-the-middle attack. A login system is only secure if both the login form and the target page use SSL.
Also, it doesn't look secure to the user. Users look for the padlock symbol on the login form, and yours doesn't have one.
Yes, it is a security flaw.
Since the form is served over HTTP, it is subject to being edited along the way. This edit could be, for example, the additional of JavaScript that sends the credentials to a server that the attacker controls as well as letting the browser log in normally.