I need to develop a REST API for a new user registration form which consists of 2 steps. Step 1 validates email and password requirements. The data gets saved into the database on Step 2 after the user specifies valid country and region. What is the recommended approach in such scenarios? Using different endpoints for step 1 and 2, like /users/password and /users/location? Using a single endpoint, but having some info about the current step as part of the Dto? Anything else?
Hi you can use both of the options i my self used both of them but in my experience using a multi endpoint is more maintainable. And also it good match for single-responsibility principle (SRP)
Related
I'm designing a system with REST API. REST API will be implemented using Spring Boot. The system should manage employee, product, orders information. It can be used as a standalone or as a part of some existing product ecosystem. I'm looking for some resource (book, blog, online course, etc.) to help me decide how to implement authentication and authorisation.
It's quite obvious how to do it if the system is used as a standalone product. User credentials/authorisation data can be stored in the same database next to product/employee and other data.
I'm not sure how to handle everything when the application is a part of some existing ecosystem. What if:
Someone wants to reuse existing User data store for authentication or third party service like Okta or Auth0.
Use existing data to build authorisation rules. For example authorise a person to modify product data if the person belongs to some User group.
I'm thinking about Oauth2+OIDC solution. For example Okta allows add a Claim based on Expression. User groups can be provided as Claims too. It seems Okta could be a source of both Authentication and Authorisation information. I'm not sure if it's a correct way to use Oauth2 and OIDC? What are potential pitfalls storing the authorisation data this way?
I've checked Keycloak and it seems authorisation data. can be stored there. So it's not an unusual practice to manage such a data in an authorisation server.
Maybe I should use Oauth2/OIDC for authentication only? Authorisation data (assigned roles, groups, etc.) can be stored in my application database. The application should provide means to manage the information.
I'd like to get some advice or source of information for this topic.
Thank you.
I would aim to keep OAuth data fairly small - the Authorization Server (AS) typically only needs a few fields to manage login such as Name / Email and a generated user id.
When data becomes domain specific it can become a burden to manage it in the AS, whereas in your product data it is easier to spin up custom UIs etc.
Instead the AS can reach out during token issuing to an API to include important claims in access tokens - such as roles etc. Meanwhile you don't want to expose detailed access tokens to internet clients.
The Curity web site has some good resources on patterns to meet the above requirements - here are a couple of links:
IAM Primer
Claims Best Practices
The title is a bit obscure. I'm interested about some feedbacks on a specific architecture pattern.
Let's take as an example the Stripe API: when you are using this API, the system is basically broken into two parts: live mode and test mode. If you hit the "/customers" end-point, you can either retrieve test mode customers or live mode customers, based on the type of API key used.
I'm asking myself how I could implement such a pattern using an OAuth 2 access token.
In my workflow, I have a single application page (JavaScript) that communicates through my API. I have a "live"/"test" switch, so basically my whole website is replicated into two distinct environments.
When I log in into my application, my authorization server creates a unique access token (OAuth 2 Bearer token), that is send for each requests. But obviously, my access token is tied to the "session", not an "environment" (live or false), so if I want to implement a switch live mode / test mode, I cannot rely on the token, because the token is "generic".
I've thought about two options:
Depending on live mode or test mode, I send an additional header to all my request (like X-Livemode which is either true or false). Then, in my back-end, I reuse this header to automatically adds a filter on all my requests.
If I switch to live mode or test mode, I ask my authorization server another access token. This would means that access token would have additional context information. However this seems a bit complicated, and I'm not sure that OAuth 2 spec allows token to have such additional information.
I'm not sure if this post is clear or not :p.
The second part of the question, is what is the best way to implement such a system where all the resources are basically duplicated between live / test mode ?
In my understand, it should be as simple as adding a "isLivemode" property to all resources, and make sure that all my SQL queries are aware of this. Is this correct?
Thanks!
A much simpler solution I've used in the past (albeit a bit of a workaround) is just to append "live" or "test" (base64 or hex encoded) to the api key, like so:
Imagine your actual key is:
9a0554259914a86fb9e7eb014e4e5d52
In your key presentation, present your key to the user as:
9a0554259914a86fb9e7eb014e4e5d526c697665
Then use a regular expression to strip off the known characters.
Alternatively, if you're equipped to handle key-value maps, a more "OAuth2-spec" approach would be to generate unique keys for live and test and do a key-value map lookup on the request to determine if one belongs to live or test.
I am creating a Web API service for an application with a single tenant database. Each company will have it's own database strictly controlled and created by us. I am aware of the maintenance implications of single-tenant databases compared to multi-tenant and we feel single-tenant best fits our needs. Users will be created by us only.
There will be a master database to "map" each user to their company database when authenticating based on only their username (email address). If there is a match on email the authentication will then continue within the client's company database which will contain the password hash.
This leaves the databases self contained which is needed for foreign keys for audit records. The master database simply acts as a mapping or routing based on username (email address).
I created a new Web API project and used the Individual Accounts template. I like the way it works but unfortunately I don't see how I can customize this enough to accommodate for my needs. Would this be possible? I need to use tokens. The only other alternative I can think of is a completely custom authentication procedure but security is not something I want to take lightly as I'm sure I will mess up somewhere along the line. I am aware that the user passes its username and password over SSL to the server which responds with a token which then gets included in the header of each subsequent request to an authorized resource. I just need to know if this is something I will have to completely implement myself? This whole thing may just be a silly model for an application in which case I am open to suggestions.
Any feedback would be helpful.
Thanks
After lots of searching I finally found the type of solution I was looking for. Dominick from Thinktecture has a blog post which details a nice embedded token authorization method which I can now extend upon. This is exactly the type of solution I was looking for as it is extremely simple.
Embedding a simple Username/Password Authorization Server in Web API v2
This is a generalization of my scenario:
the user of a client app, when challenged for security, could choice to authenticate using more than one method, each one different as parameters (and backend systems to be called, in a more complex scenario).
for example:
- choice A using (id, pwd)
- choice B using (name, cellnum, token)
- choice C using (platenumber)
I'm thinking about a possible first solution where define different "submitAuthentication"-like backend procedures, each one with different signature, that the client calls based on the user's choice.
A possible second solution (really I don't like), to have a single "submitAuthentication"-like backend procedure where first parameters determines the kind of the choice, and following parameters will be mapped on the expected ones.
Is there some guidelines in order to realize that?
thanks.
There are multiple ways to accomplish utilizing multiple inputs for authentication. I would suggest looking over the authentication presentations and accompanying samples provided by Worklight:
Authentication Concepts:
http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/08_01_Authentication_concepts.pdf
Form Based Authentication:
http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/08_02_Form_based_authentication.pdf
Adapter Based Authentication:
http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/08_03_Adapter_based_authentication.pdf
Custom Authenticator and Login Module:
http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/08_04_Custom_Authenticator_and_Login_Module.pdf
As I stated looking at your above scenario you could take many routes to accomplish this. I would say your decisions would mostly be based around what design the login would have on the client side. You could have something as simple as having the user choose what kind of login credentials they want to use and have the different situations handled in your challenge handler.
I'm trying to implement a multi-step registration process. This particular implementation involves OmniAuth, but for the purposes of this discussion it could well be any OAuth provider.
Here are the registration steps we might implement:
Step 1. User clicks Connect with _________.
Step 2. Authorize via _________ and redirect to callback. Pull relevant data from provider and save to your User model.
Step 3. Pick a username, fill out email address, and any other required data for registering for your app. Also save this to your User model.
The problem for me lies in the transition from Step 2 to Step 3. I could set validations on the data based on state, using something like state_machine, for example.
However, I would have to remove not-null constraints at the column level for certain essential pieces of data, like username in my case (which is used for user routes), or email. I'm not super comfortable removing another layer of data integrity.
I'm sure this problem has been solved a thousand times before. How have you handled it and how would you recommend I handle it?
Could you add the data from the provider as hidden fields in your form for step 3 to pick username, email address etc? This way you wouldn't be creating a User instance until you had all of the data available.