I've built a small api.
I Would like to implement header authentication for my api.
When user want to access my api he will send his apikey along with the api url. If the apikey was in my database then he will be given access, if not he can't access the api.
if you want to authenticate a single method
then you can look for the header directly in the method itself. something like
#GET
public Response processRequest(
#HeaderParam("X-APIKEY")
#DefaultValue("INVALID_OR_GUEST_KEY") String apikey , ...)
if you want to establish this for -all- (or most) of your methods, then you are better off with a filter. Take a look at http://www.dropwizard.io/0.9.2/docs/manual/core.html#jersey-filters and http://www.dropwizard.io/0.9.2/docs/manual/core.html#servlet-filters .
You can implement your key lookup logic in there
(PS you may want also to consider caching them, but that's another story).
Related
So I am creating some api's on Laravel using Passport (JWT).
I am having issues deciding what is the preferred method for the following:
PUT: api/users/{user_id}
PUT: api/users/me
I need the api so that the user can change his own information, but I would also like it for the api to be accessible for the Admin to change said information.
At the moment I am only using the first API and checking if the ID is the same as the one in the JWT auth or if the one requesting the api is the Admin.
But I was also thinking that maybe it was better to have them separate. The first api should only be accessible to the Admin, and I should be taking the ID from the JWT auth for the second api.
What would be the correct choice? Or is there a better choice?
I would say using this approach is better:
PUT: api/users/{user_id}
That allows anyone to consistently link to your own profile or to some other user profile in the same way. Then depending on your authentication and authorization, you can be allowed to do different operations on that resource.
There is no correct or better choice. You seem to understand the implications of using any of them so it's really up to you to choose. With the /{user_id} version you have to be extra careful not to remove proper validation rules from your code. If you used /users/me for a GET operation you would have to be careful with setting cache headers. If a browser would cache a response to users/me and then another user would request this endpoint, then you could get some other user's data. For PUT operations, though, this is not a concern.
I want to retrieve data from a data warehouse that has a web-based API, I need to use an API key for authentication and use the GET / Customers command to retrieve the list of customers data, but when I am using that same thing in postman, it's returning the same documentation page of the data warehouse?
I am new to this any help will be really appreciated.
The URL doesn't look valid:
You need a base URL, endpoint, http method, authentication scheme, and credential or a token etc.
I don't know details about your system and API, so let's see an example:
base url is https://stackoverflow.com; your current base url is localhost:4444, is your server running on your machine? If so, it might be correct, but I assumer you're talking about a server running somewhere else, not on your computer
endpoint (path parameter) is /questions/69883697, in your case /customers
http method is GET and you find it here in Postman; it also means it will not go into query parameters where you put it:
authentication scheme - your docs mentions an api key that goes into a header called Authorization, so you have to set it in Headers, not as a query parameter:
Read carefully what's on your screen, Postman uses the same language as your API documentation, so if your doc speaks about headers, you need to go into Headers tab in Postman.
Let's say that users X and Y authenticate themselves (separately) on a service's REST API, and that JSON web tokens are used for authorization between the client and server. We want to send user-specific data to each user.
Should we ask the user to specify who they are, or should the server detect it based on the authentication method (in this case the payload on the JWT)?
In other words -
Should the API have endpoints that look like this:
GET /:user/resource (for example) /user_x/resource used by user X and /user_y/resource used by Y,
or would it be better to have
GET /resource and then, in the route handler, check the user id (as part of the JWT payload) return data based on the user id?
I'm not sure which of these (if either) is the best approach, or if there might be another way to do it, such as using query strings. It would be great to hear any opinions about this.
Thanks.
The server can identify the user based on either a session cookie, or an access-token. In your case, if you use a JWT, the user-information is usually already included in the token.
So the server should just fetch the information out of this token.
Just make sure, that you check the tokens signature on the backend.
Otherwise, an attacker could just modify the JWT and send a different user-id to the server.
I am currently using Openiddict, Identity and Entity Framework to manage my users and assign Bearer tokens to users to protect my API.
My infrastructure is currently using ASP.NET Core Web API in the back end and a separate React application in the front end. The React application makes HTTP calls to my API to retrieve it's data. There is no server side HTML rendering at all in the back end.
Everything works as I need it to for the most part. I can register users and retrieve tokens from the API. These tokens are included in my HTTP call in the Authorization header. My AuthorizationController uses this: https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Controllers/AuthorizationController.cs with a few minor tweaks. My Startup.cs also uses almost exactly this https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Startup.cs
In some instances, I need to make API calls to the endpoints that are specific to the user. For instance, if I need to know if a user has voted on a comment or not. Instead of passing along the users ID in a query string to get the user details, I would like to use the Bearer token I received that they use to make the API call for that endpoint. I am not sure how to do this though.
In some research I have done it looks like some samples use ASP.NET Core MVC as opposed to the API to retrieve the user with the User variable as seen here https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Controllers/ResourceController.cs#L20-L31 however this seems not to apply to my infrastructure.
My question is how do I look up a user based on the Bearer token passed to the API to look up a users details from my database? I am assuming that all of the tokens passed out by the API are assigned to that specific user, right? If that's the case it should be easy to look them up based on the Bearer token.
The question is: How with Openiddict can you look up a user based on the token that was assigned to them for API calls? I need to get the user details before anything else can be done with the application first. Is there something baked internally or do I have to write my own support for this?
When you create an AuthenticationTicket in your authorization controller (which is later used by OpenIddict to generate an access token), you have to add a sub claim that corresponds to the subject/entity represented by the access token.
Assuming you use the user identifier as the sub claim, you can easily extract it from your API endpoints using User.FindFirst(OpenIdConnectConstants.Claims.Subject)?.Value and use it to make your DB lookup.
I have an API that provides an Account resource based on the authentication (login) that is supplied. As a user can only have one account, and can only see it's own account and not those of others, this API will basically be a single resource API in all cases.
So to keep things simple, I have this resource under the url accounts/ and when you access accounts/?username=dude&password=veryhard you'll get your account data (if you dohn't supply authentication you'll get a 403).
Now I wonder if this is RESTful. Also, you should be able to update your account info, and I wonder if PUT would be appropriate. In my knowledge, PUT should be done on a unique URI for the resource. Well, is this a unique URI for the resource? Generally a URI for an account would look like accounts/3515/ where 3515 is the account id. However, users don't know their account id. Also, there should be more ways to log in, instead of a username + password you should also be able to use a token (like accounts/?token=d3r90jfhda139hg). So then we got 2 URL's that point to the same resource, which also isn't really beautiful for a RESTful URI, is it?
So, what would be the most RESTful solution? Or should I not do this RESTful?
REST purists will consider that use of /accounts/ to obtain a single account is bad practice as it should specify a collection. Instead consider a key which cannot be mistaken for an ID, for example if your IDs are UUIDs then use a token such as 'me' so your URL is /accounts/me. This has the advantage that if later on you wish to obtain different account information, say for example you need to list users or you have an administration system using the same API, then you can expand it easily.
Putting username and password in the URL is also not pure REST. The query parameters should be directly related to the resource you are obtaining; commonly filtering and limiting the resources returned. Instead you should seriously consider using something like HTTP Basic authentication over an encrypted (HTTPS) connection so that you separate out your authentication/authorisation and resource systems. If you prefer to use a token system then take a look at oauth or hawk.
Finally, yes if you use PUT you should supply a full resource identifier. Given that it is very common for systems to read data before updating it the lack of ID won't be a problem as that will come back as part of the prior GET.
Yes accounts/?username=dude&password=veryhard is a correct REST URL.
PUT is used with an id if it used to update a resource, if you use it to create you must supply an ID. otherwise you use post to create a resource without id