One of requirements for implementing a REST Api is that the client has to send the required state information every time to the server to handle a specific request. Assume authentication is in place and I'm successfully authenticating users to use the rest api, which means with every request i'm verifying that user has rights to access the api.
What if I have multiple users and each user has a different access right. So each user can only call a different set of webservices. I'm wondering how this is normally handled by the server. I figure the only way to do this is to check the authentication of each user(via a password hash code,etc) with each request to verify that he has access rights to the requested service. If that is correct then what are the recommended ways of handling authentication of multiple users in such a scenario?
I'm using flask to develop my api, so any specific suggestions will be much appreciated :)
Thanks in advance.
Authenticate a user first by username and password. Return back a token or hashcode.
Prior to any action you take on the servers api, check the users permission by using the token.
You always want to check permissions on the rest api. They can all make the call to the api. Their permissions is what will determine if they can or can't do the request.
Related
I'm trying to implement Google authentication for my app and the below is the workflow I'm trying to set up.
First, user will authenticate with Google and obtain an access token.
User will make requests with this token to backend services.
Backend services will check with Google to validate these token
Once validated, backend services will send information requested by client back to users
And I have a couple question around it:
Is this the correct way to implement it?
How to avoid check with Google for every single request between Backend and Frontend?
It's sort of the correct way. It depends on the details. If I understand correctly, you are in control of the front and backend (these are both your applications). If this is the case, then you would rather use Google services only to authenticate the user (so use an OpenID Connect flow to get an ID token to verify the user's identity). After that, you would have your backend either issue an access token or establish a session with your frontend. Then you wouldn't have to ask Google for the token's validity every time someone makes a request to your backend.
An access token that you get from Google, Facebook, etc. is meant to be used with their APIs. You could use it to authorize access to your own backend, but you then have to call Google on every request to verify the token. You are also tightly coupled to Google's details of the access token usage — what scopes are available, what data is returned with the token, expiration times, etc.
If the access token is a JWT, then you can verify it on your own in your backend. You don't have to call the issuer every time. But, if I remember correctly, Google issues opaque tokens, so this is not the way to go here.
To sum up. If you're in control of the front and back end, then authenticate with Google, then start a session between your applications. This will be simpler to maintain and also safer, as you wouldn't have to handle tokens in the browser.
I am very new to the concepts of SSO and Keycloak. I am trying to read the official documentation of Keycloak. In the "Supported Protocols" part (https://www.keycloak.org/docs/latest/securing_apps/index.html), the documentation talks about the two use cases of using OIDC like this:
"The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request."
What I do not understand is this: In the first paragraph it talks about an application making a request and in the second one it talks about a client. But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Thank you.
But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Yes exactly it. The reason for the differentiation is because there could be many applications more than just this one client. And the client, that the user is authed against may want to access all those other applications' data.
For example take the google ecosystem. Does google email have access to drive, and photos, etc... While it could out the box, it doesn't. You need to explicitly allow email "offline access" to those other applications, even though they are all part of the same platform.
Keycloak understands this and provides that terminology. But it is a bit confusing because this isn't the best way to think about it. Instead a better explanation is that there is just the user and service clients. The service clients all talk to each other and ask for a user's data. While a user may want their data by going straight to one application, other applications may want that user's data too.
Assuming you want to actually allow one service to ask for user data from another service, you want to be using something that supports authorization as a service and not just authentication. There are some examples of this, such as PolicyServer and Authress.
Is there any method to modify i.e. playlist by Web API by with console based application in Client Credential Flow ?
https://developer.spotify.com/web-api/authorization-guide/#client-credentials-flow
Propably not, but maybe I am wrong ? I want to modify only my user's data.
Here I created issue at API specification
https://github.com/spotify/web-api/issues/165
One of the benefits with the Client Credentials oAuth 2.0 flow is that applications can make authenticated requests to a web service without a need to involve an end user. Since a user isn't involved, the requests that can be made from the application is limited. For example, using Spotify's API, you can still make requests to retrieve track metadata, playlist contents, and search for albums. Any endpoint that requires a scope can't be used since it requires user interaction.
So using Client Credentials simply doesn't make sense if you're interested in making requests on behalf of a user, or if you want to access private data since the user needs to give you permission first.
You need to use Implicit Grant or Authentication Code Flow for this. I advise that you read further about the supported oAuth 2.0 flows in the Authorization Guide. One of the benefits of using the Authorization Code flow is that you'll also retrieve a new refresh token, which you can use to retrieve access tokens indefinitely. It however requires you to write a web service that accepts an authorization code and exchanges it for the tokens. The Implicit Grant flow doesn't return a refresh token, so it's only possible to use for one hour until the access token has expired.
I am creating some APIs and I am confused about how my application will authenticate, basically because I feel I need 2 authentications and I cannot find any information about this.
Authentication with the API Server (so my app will be able to retrieve data and sync even if no user is logged in)
Users authentication
Is one endpoint (i.e. /login ) enough to manage all this?
Any ideas?
Thank you!
In this case, use an HMAC on the incoming request with a preshared key to authenticate the user. Then on your resource (in the Controller), validate that your user is authorized to access the route.
I am creating a REST inspired API for a Learning Management System. It will expose data such as users, classes, grades, courses etc. I have defined all the resources I want to expose, given them each an endpoint URL, and defined the JSON resource structures that are returned.
I now want to understand how to secure the API using Oauth2 (I don't want to use Oauth1). Am I correct in the assumption that my API will play the part of both the Authorization Server & the Resource Server? Also, what grant type / flow should I be researching?
A lot of the tutorials seem to focus on using Oauth2 to login using facebook credentials etc - but I just want to use it to secure my API and allow my users access to my API (either through a client, or directly). The access permissions for the API should follow the individual users access permissions that are already handled within our system.
Sorry for the scatter-gun questions - I just don't understand oauth2 enough to know where to direct my research. Any help would be greatly appreciated, and any pointers to simple tutorials for the correct use case would be great too.
FYI - The system is built on a LAMP stack using Drupal 6 (old, I know).
Well your assumption is correct the authorization server and the resource server can be on the same server or in the same API.
So how the OAuth2 basically works you have some kind of client(Server, Browser) Authorization API will authorize with Access Token to use your resource API which is then sent in the the Authorization HTTP header on every resource request.
So what I success is that when the user logs in, you identify the user and generate the Access Token immediately to the client. Now you can put some data inside the Access Token e.g. userId, permissions etc. Now when the Access Token hits your resource endpoint you can identify the user and check the permissions. Also you can just make the Access Token dumb so it doesn't contain any data then when you validate it from Authorization API(on Access Token creation you have to store info about the user to Authorization DB), you can get the info you need on the response e.g. userId, permissions etc.
What grant type flow to use, this is basically up to question what kind of clients are using your Authorization API and how secure you want the Authorization to be. E.g. implicit grant is for browser based clients which can handle redirections and e.g. Client Credentials grant is for (server-to-server) communication.
Reference here
To start with, you can use existing providers like WSO2 API Manager for supporting your system. It is well documented and has many REST APIs for this.