I need to implement an email verification mechanism in play after after the user has registered on my website.
I am trying to understand what is the best architecture, this is my guess:
Define a special route for email validation
When the user register generate a token and save it inside the cache with a token -> user mapping.
Send an email containing an url which points to the route providing the token as a parameter
In the special route controller, retrieve the user from the cache using the token, validate the email and store it in the database.
Is my approach right?Is there a better solution?
There are modules out there that provide this functionality for Play 2.x. You might want to take a look at Secure Social, or Play Authenticate (as mentioned in a comment to the question by #biesior).
Related
I'm creating an OIDC provider with oidc-provider. For now, my Registration flow required email verification step, which is handler outside oidc-provider. This approach works but it leads to an issue that user can not automatically login after setting up their password.
I thinking of creating a new prompt policy name email-verification, something like:
https://<auth-endpoint>?client_id=...&prompt=email-verification
I wonder:
Is this flow acceptable with OpenID Connect specs?
Is there any document, tutorial or example in terms of specs or implementations of this approach?
The case user register in mobile app, but open email link in web (we have a mobile app with different client_id and of course, different redirect_uri. What should we redirect user to the app without error.
Thanks,
I want to add a question into the Keycloak auth flow after the user’s name and pw have been authenticated to ask what type of two factor authentication they prefer. The choices are OTP or SMS. If the user has already made the choice before, I will skip the question and continue to either OTP or SMS authenticators. Need some advice on how to implement this.
I have created an authenticator class that shows a template. Is that right? I have seen examples of creating a required action.
How do I skip the question if the user has already made his choice? I tried using returning false from configuredFor() but that just halts the flow with an error since my authenticator is set as required.
I plan on storing the user’s choice in a user attribute or possibly a cookie. Any thought on which is better?
As always, thanks.
You can use a Conditional authenticator to check the condition, there is an example of this in the server developer documentation: https://www.keycloak.org/docs/latest/server_development/#algorithm-overview
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
What is the best practise for authorization and authentication of users in REST spring boot?
I am building web app with standard pages + REST API for mobile. I looked at many articles about Spring security and basically most of them goes with some sort of fitler approach that will allow or block REST calls. In my case, however, I have some auth logic based on who the user is. For example, there is a /update API that updates user information, and user can update himself, but cannot update other person.
Initially I thought to use next auth schema:
User calls auth API and pass name/password or cookie
System generates short life token, saves in it's database.
User get this token, updates his cookie (so JS in web application can read and use it)
When REST call is being make cookies are passed. At Controller, token is extracted, checked for expiration, query is done to database to validate token and get user id.
Based on user id, REST will be permited or blocked.
Is this the right approach to implement? I have a pretty big mess in my head after reading articles about spring boot security.
At least: session auth will not work for me (REST is stateless). I want to make auth for mobile device without storing login/password there.
Does it make sense to pass this token in the REST body itself? What in case of GET method?
Many thanks for sharing your knowledge.
Did you find a solution to your problem?
I have answered this problem elsewhere, if you are sure you won't want to open up the API to other developers/clients in the future (if you do then you should look at OAuth) then a simple token based solution will work.
Something basically along the lines of this:
Setup a standard html login page, that you can use for user login to the app
setup spring security to return a cookie on sucessful login with an authentication token
in your mobile app, embed a WebView (or equivalent) and load this login form - allow the user to login via that webview, on response grab the cookie and store the token (as mobile is generally single user, you can keep that pretty long to save mobile users having to keep logging in)
Add a security filter to the the REST API to authenticate against the token (from the mobile app pass the token in the header for example) - then you will be able to use normal spring authentication context for current users etc.
This approach is suggested by Google here: (EDIT: Google seems to have changed the page I originally read to be about using Google+ sign in and OAuth2.0 - I can't see a link to their general Mobile/API docs so here it is in the web archive :) )
I have also written up my implementation here:
Overview of the approach using Spring security
The code & details
Although this was really just an experiment/Proof of concept, it might be useful in your thinking.
Cookie approach seems perfect for the use case. Token can be tied up with user id. Filter can extract cookie and pass user id for example as header to apis - that should take care of GET...
We have a Portlet running on Java/J2EE technology. It interacts with another application/system through HTTP request that requires user authentication. The current solution retrieves logged in user's user name and password from the Portal, and passes this information to back end systems using "HTTPClient" API's to retrieve content based on user's authentication and authorization.
There are efforts to enable site minder for the Portal. With site minder enablement, the Portal no longer provides logged in user's user name and password. The ideal way would be that back end application also has site minder enabled so that Portlet could pass the login token or cookie value.
Looking for interim approaches until the back end application is SiteMinder enabled. Is there a way we can enable/force user to enter user name and password ? I cannot think of such possibility because the Portlet code (using HTTP Client accesses the back end URL of the application, its not the browser). One possible way I can think of is, develop a new screen(UI) to have user enter user name and password within the Portlet and use that to authenticate with back end system through Java code. Please let me know if any other ideas.
Also, let me know if the question is confusing, I will provide more details.
Thanks
Siteminder can provide user information dynamically to connected applications in HTTP headers (uid, email address, etc.). This behaviour is configured on the Siteminder Policy Server. By default, the HTTP header SM_USER (or similar) contains the username of the authenticated user.
Then, you have to adapt your portlet code to fetch those headers from the request and feed it to the back-end application like you used to.
I wouldn't advise the use of the SM_USER header for tracking users. SM_USER contains the ID that was provided to the credential collector, and will change based on the type of authentication scheme used.
Example:
If you have an HTML forms based auth scheme that collects email address instead of UserID, the email address will be sent in the SM_USER header. In the case of an X.509 auth scheme the SubjectDN from the certificate will be in the SM_USER header.
The better choice would be to use the SM_UNIVERSALID header as that will always contain the Universal ID attribute. The Universal ID attribute is configured in the User Directory object (typically this is set to "uid").