Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I have an application with
Front end Angular Component
Login service - validates username and password and provides JWT token(Service A)
Book Tickets service - Save/retrieve data about ticket bookings
Note:
Login and Booking service has its own DB.
Not using an API gateway
Flow:
Front End <-> /authenticate(ServiceA) <-> validate creds on login DB and return JWT token.
After this call, I would require the Book Tickets service to be authenticated by passing the JWT that was created in the previous step. But how can I do this without connecting the LoginDB to the Book Tickets Service?
What I was hoping to do (But unsure if they are good practices) :
Create an endpoint in LoginService "/isValidUser" and call this endpoint from Book Tickets service every time.
Route all Book tickets service endpoint through Login service so JWT is validated and the request is forwarded.
Let Book Ticket Service access the Login DB and implement JWT validation in this service itself.
Really appreciate you suggestions.
In Microservices architecture mostly one service talk to another service using standard interface or say web api.
In your case, you are right that you need LoginService and it has following responsibilities.
Validate Crendential ( Username , Password) and return JWT Token.
Now this token will be used by Frontend to communicate with Backend or other services like Book Ticket Service etc.
IsTokenValid
Now Book Ticket Service has following responsibility.
Booking Ticket.
Possible flow of Booking Ticket is like.
/bookingservice/BookTicket ( with all data)
Also JWT Token pass in header.
BookTicket service will receive request and it also extract token from header.
It will pass token to Login Service to validate that token is valid or not.
If it is valid then you can perform book ticket.
If you allow Book Ticket Service to access Db of Login Service, overall purpose of Microservices will not be there. Because as soon as there is some change in Login Service DB, you also have to change Book Ticket Service.
For small project like once you are creating and then you are not going to change for long time then it may be ok but in that Microservices purpose is not there.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I am trying to venture into the full-stack development realm during some of my free time, and I just have a few general questions about my current understanding of OAuth2. I am very green when it comes to this stuff, but I've watched some Udemy videos to gain a basic understanding.
Anyway... this project that I'm working on, I'm planning on having a custom authorization server, a resource server, and a single client (which will likely be a SPA). This authorization server will only allow the authorization code (probably with the PKCE extension) grant type. Which leads me to my first general question...
Intuitively, I assumed that the password grant type would be sufficient. As I've done more and more reading, it looks like this grant flow is not the way to go. As I understand it, using this flow would require the client to provide some form so that the user may login. Doing so gives the client access to user credentials, which very much defeats one of the purposes of OAuth2. I'm not sure this is an issue with what I'm developing, however, because I am creating the authorization server. I know by using this grant flow, I am not validating the client. Can someone explain how this might be an issue? Is there anything else I'm missing here? Everything I've read has deterred me from using this grant flow, which is mostly why I ended up deciding on the authorization code (w/ PKCE) flow.
So... assuming I go with this flow, my client should provide a login button. Pressing this login button will re-direct the client to a web page where the resource owner can authorize the client and provide user credentials. My authorization server will then validate these user credentials. I plan on storing user credentials in a database on the VM running the auth server. I don't plan on allowing users to register an account. Instead, I'm just going to have a static list of account credentials in this database for people on my team. So I guess I'm just going to insert these accounts when the database is created? If so, how do I allow these users to change their passwords? I guess I'm thinking that initially these accounts will be assigned an e-mail, username, and random password that I can communicate with them. However, I'd like the user an option to change this random password to something more familiar. I don't currently know how to do something like this with the OAuth2 implementation. Do I just provide a way in the client to change the password when the user is logged in? If so, doesn't this somewhat defeat the purpose of using OAuth2 as now my client would have knowledge of the user credentials? If I were to do this, however, would this just be implemented as a POST request to a REST API at the auth server for updating the password?
I would start by using a free cloud provider as the Authorization Server. Have a look at the following tutorial of mine, which uses Authorization Code Flow + PKCE:
Blog Post
Easy to run SPA and API Code Sample
This sample uses AWS Cognito which is a fast option for getting started. It will enable you to create users - they will then be prompted to change the password on the first login.
The important points are these:
Write simple standards based code in your apps and spend time learning the recommended flows and design ppatterns
Once code is written you should be able to switch to a different Authorization Server later, if needed
Avoid building your own Authorization Server, and use one that has been provided by specialists
You should only need Spring for the resource server (my API above uses Node.js). If you want an easy to follow Spring resource server sample maybe see this one.
I'm sorry if this question is asked before, but I'm still confused.
I'm currently creating a REST API with laravel. I'm using passport to secure the API-endpoints. The API should be used/accessed from several websites and SPA's. BUT all this sites need to access the API on there own behalf. So there is no user that need to sign in! I found a lot of tutorials that cover the topic of authorization and authentication but only on behalf of a user.
So my question is: What oauth grant type shoud i use to secure my API considering that all api consumers act on there own behalf?
I tried to use the client credential grant because the documentation said that
The client credentials grant is suitable for machine-to-machine authentication.
But that creates a bearer token and it seems not save to store it in a SPA or generally on client side.
Has someone experience in this topic and can please provide an answer (maybe with a short explanation)?
A simple example of how I want to use some endpoints of the API to provide some context:
I created a location endpoint that receives a zip code and returns all the relevant places. I want to use this in a form. So that the user inputs his zip code and dynamically receives all the places in a select box, so that he can choose one and proceed with the form.
Thanks in advance!
My client app contains user registration page that will contain
information like - email, country, address and some other
demographic details related to the user - in addition to username
and password. What is recommendation on to persist this information?
Auth Server must only persist username and password and all other
details should be persisted in the Resource Server? I need all the
User information when I access protected endpoint in Resource
Server. What if I create another Resource Server in addition to
existing one - then I end up duplicating all the information again.
So I am thinking I should store all the user details in Auth Server
so as to have single source of truth about the user.
If all user details are in Auth Server, how do I make that user information
available to every protected endpoint in the Resource Server? What
changes I need to make in Auth Server and Resource Server to make
this happen?
Good question - it is a design question and the best option is to separate concerns
I would recommend handling it via claims and to keep central + product user data separated:
https://authguidance.com/2017/10/03/api-tokens-claims/
Happy to explore any follow on questions with you ..
Meant to say: your user registration page should save data to 2 different sources - it is tricky - but worth taking the time to get right ..
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've implemented a basic authentication system with Spring Boot, Spring Security, OAUTH2 and JWT as auth tokens. It works alright but I was thinking if it makes sense to store JWT in a database and check if a token exists every time someone makes an authenticated request using it? I was thinking specifically of the following scenario: user is authenticated in a mobile device and they lose it so they want to deauthorize that device. They would then be able to issue an operation that clears the tokens issued to their user id and deauthorize all tokens assigned to him. Any other way? Am I thinking this wrong or overcomplicating things?
This is for securing a REST API that is going to get called from a mobile APP.
You could store the JWT in the db but you lose some of the benefits of a JWT. The JWT gives you the advantage of not needing to check the token in a db every time since you can just use cryptography to verify that the token is legitimate. If you have to look up the token in the db, you might as well just use an opaque token that doesn't carry information with it and let the server and database provide you with the information. On the other hand, if you're going to store a token in the db, I don't think a JWT is a bad choice for your token type. As you say, there are advantages for revocation if you store your token in the db. It all depends on what you want to achieve (faster authorization, etc. vs ability to revoke on demand).
You can still use JWT with OAuth2 without storing tokens in the db if you want. JWTs have a configurable expiry time that you can set--after which they are invalid. Access Tokens (whether JWT or not) should usually be short-lived for security. If the concern is someone's phone being stolen and access tokens being obtained, I think the solution is to have those tokens expire quickly (30 mins?). If you're using oauth2, the means of stopping someone from continuing to use the app is for the real owner to de-authorize the mobile app client on the authorization server so that no more access tokens will be given out.
You can set expiration date (for mobile 1 week).
Add some custom field refreshId for user (you can use uuid for this).
Next set Issued at claims parameter ("iat").
Store refreshId into db and set it as claims parameter .
Then every time when you validate token you should check the token's "age". If it older than one hour you should load data from DB and check refreshId value and create new token with current "iat" value and send it to mobile device. When you need to deactivate tokens just generate new value for refreshId in db. After one hour all tokens will be incorrect, so user will need to login on every device again. You can make more custom solution if you need to.
I'm new to spring boot and I want to integrate openId provider into our application. I have searched a lot about it but didn't find any suitable article from which I can start.
Problem statement:
Once user hits our websites url(ex. www.abc.com) the user should be redirected to openID provider's(login page) server where the user puts username and password or register him/herself.
After successful authentication, user then given the access to our application where in application needs to retrieve few informations about user (basically data exchange between openID provider and application).
how exchange key to generate a shared secret-key?
I have end point of openId provider and service discovery endpoint.
Would someone help me out with this?