BACKGROUND
I am currently building a microservice where I want to use Keycloak as my auth-server. I am not that familiar on Keycloak yet and I want to check first if the data provided by the user are all matched and existing on the DB before proceeding with the sign up. If the data are in the DB, then add the user.
QUESTION
How can I add a checking in DB first (This is done by calling a microservice) if all the data are matched and existing on the DB before adding the user?
If I can not do this or it is going to be hard, what alternatives can I do?
Also, in the future I am trying to add an OTP for a certain endpoint/s. So that before proceeding with a post request it will go to an OTP first, but there should be a login by username and password first before accessing the endpoint.
Related
There is a lot of good content on the internet that explains how to secure a Spring API with Keycloak: Create a Client that represents the API Service in Keycloak and use a link like the one below to get the access and refresh token:
<Domain>/auth/realms/<realm>/protocol/openid-connect/auth/{some parameters}
This yields both tokens. So far so good.
Now, however, I am not sure how the flow for the frontend accessing the API should look like.
Should the frontend directly access this endpoint and, therefore, obtain the access and refresh token? That would mean that the API can only have the access-type public because there is no way to store the client (the API) secret securely.
Or should there be a third server that somehow stores the refresh token for each user, that the user can call if his access token is no longer valid. This server would then use the client's refresh token (and the client secret that could be stored securely, since it would be in the backend) to get a new access token from Keycloak and would forward it to the user.
I guess the main question that I am asking is, whether the client/user should get the refresh token.
If one needs to implement a logic according to the second option, I would be interested in a link or description of how something like this can be done in Spring.
I think, in either case you need to use the Authorization Code Flow. The implicit flow, which was recommended for SPAs (frontends without a backend server) in former versions of OAuth2 must not be used anymore.
The best option is to have a backend server, so the user retrieves the auth code via redirection and the backend server exchanges this auth code with the access and refresh tokens (and keep them without forwarding them to the frontend).
If there is no backend in place and your frontend needs to retrieve and hold the tokens directly, I would recommend to use the Authorization Code Flow with a public client and the PKCE extension (which - put simply - ensures that the entity asking for the auth code is the same as the entity asking for the tokens and that the auth code was not stolen and used by a foreign entity). There are several sources with more detailed explanations, which might help you, for example: https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
Hope this helps you with your architectural considerations.
I am using TDD to implement APIs for an authentication system in Laravel. This system uses the one-time-password (OTP) method for authentication. In the first step, an OTP token is issued for the user and stored in the session. In the second step, the server receives a request containing an OTP token from the user and checks if the received OTP token is identical to the one stored in the session.
I have written a test for a scenario where the user sends an invalid OTP token to the server, but I don't have access to the server session in the test, so I cannot compare the invalid token against the session value.
Is there a better way than using sessions to implement this? Is there a solution to access the server session in the test?
Thank you all.
Database
Add a column to the users table for OTP
Step 1:
generate OTP and issue to the customer
Store OTP in database
Step 2:
Server receives request from user with OTP
compare against value in database and delete from database
Pros: Simple to setup
Cons: Additional database queries and need to remember to delete it even if after issuing OTP to user request from user is never made
Cache
Step 1:
Generate and issue OTP to user
Store OTP in Cache
Cache::put("otp-{$user->id}", OTP, now()->addMinutes(5));
Step 2:
Server receives request from user with
Check against the value in cache
Pros: Simple to setup and OTP can be destroyed automatically
Cons: Cache management becomes vital area of application
Before adding, yes it works when I give the entire url like http://localhost:8080/onedrive/oauth2/success/1 in the list of uri in azure uris. I am using code flow to authroize these tokens.
But as per the docs, it should work with me just mentioning the domain name there, like http://localhost:8080. Which it doesn't.
I want to do something like send the user id along with every request for me to keep track of which user I should link this accees token to, and have no idea to do so, if this issue is there. My current application logic is, when my application sends the user details and calls my spring API, I want to handle all these transfer of tokens in the server side, so I want to transfer this userId as my path variable. How do I go about doing this? Has anyone done this, can they explain to me any other different solution?
You can't add custom details to OAuth redirects and it is best practice to always register the full redirect uri.
In terms of tracking the user, after login the token has a user id and you can also get fields such as user name and email - so both the UI and API will know which user each token is for. I can provide further details on mechanics if needed.
The user id in a token is often a generated value, whereas the user id you want to use in API path segments is maybe a user id from your app's back end database - if so you will need to map between token details and database details.
If you provide redirect uri as http://localhost:8080/ then it means you are handling the api response in
/
endpoint and not
/onedrive/oauth2/success/1
To get to know the user to whom you are linking, few ideas which you can use are
1) Use security to obtain the logged in user credentials (Ex: Principal if you're using Spring security in java)
2) After successful authentication, use the user id you have and send one more request to backend and store it database with userid as a key
I would like to set up an IT solution based on the Front / Back principle.
Front side I would use a technology like React, Angular and Back side I would use a technology like java spring boot to implement controller Rest.
The front will make Rest requests on the back to retrieve data.
I would like to add a security concept to the solution by implementing the JWT standard on the back. Thus the client, knowing the secret, could request a token back and could make requests by specifying the token via the header of the request.
I found several tutorials explaining how to set up this type of solutions. In particular: https://medium.com/#nydiarra/secure-...n-e57a25806c50
In this tutorial, we assume that we define somewhere (here in a H2 database) the different users of the app and their role (admin or standard).
So the front could ask a token but it would have to indicate the user and his password and the secret defined. The back looks in the database and gives a token relative to the role defined for this user.
My question is simple. Do we have to define users and roles if we want to use JWT?
What I would have liked to do is not to inform and not to store potential users and their roles.
Simply the front requests a token with the secret without giving user and the back gives a token. Which will be used later in the header of the requests.
I want to secure my RESTful webservice in some way, i read for past few hours about spring security and I am not sure if I can achieve what I want with it.
Here is typical scenario:
User tries to access www.address.com/rest/getSomething - he gets 401 Unauthorized and he is not redirected.
He goes to www.address.com/rest/login with username and password parameters
His credentials are checked against those in database (I'm using JPA over Hibernate)
If they are correct user receives 200 OK, and info that he's logged in is stored in session, so he does not need to send username and pass when accessing other addresses. Info that he logged in succesfully (or not) is stored in DB
If login is unsuccessful he receives 401
User uses webservice as much as he wanst (on each access, his session is checked)
After lets say 10 minutes of inactivity his session ends, and he needs to log in again
He may visit www.address.com/rest/logout to logout properly (session invalidate maybe?)
I also want to introduce some kind of password recovery, if user accesses www.address.com/rest/remindPass an email will be sent with newly generated password.
EDIT:
And i forgot, about one more thing. I also need another filter for checking if user has enough privilage to access an address.