This question already has answers here:
How to protect public APIs (no credentials) from being exploited?
(1 answer)
Protect a public API
(2 answers)
Closed last month.
This is a generic doubt.
How can I protect an API endpoint from automated script attacks?
For example, I have an endpoint, in which I sent the Login OTPs to users and my client app is a web-app.
As endpoint will not have any authentication required, using a script, a third party can send as many requests he wants to the endpoint.
Since we are sending OTP using this endpoint, this will cost me a lot of money.
How can I overcome this situation?
Related
This question already has answers here:
Do sessions really violate RESTfulness?
(9 answers)
Closed 4 months ago.
For web api to be rest it should be stateless.
if we use JWT authentication then we need to track user with JWT the how we can say that API with JWT token is rest?
For web api to be rest it should be stateless.
Correct.
I'll quote Roy Fielding's paper (emphasis mine):
5.1.3 Stateless
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
if we use JWT authentication then we need to track user with JWT
(I assume bv "JWT authentication" you mean a HTTP Authentication scheme using the Bearer scheme with the HTTP Authorization header, where the header's <authorization-parameters> field is the JWT token itself).
When a web-service authenticates and authorizes requests using self-contained bearer-tokens it means the clients have to retain those JWT tokens - not you or your service. The clients will get their JWT tokens from the IdP that your service defers authentication and profile/id info to.
the how we can say that API with JWT token is rest?
Because:
holding of client tokens is (by default) the responsibility of each client. Ergo, the client holds session state.
Fielding's paper states "Session state is therefore kept entirely on the client.".
...which is in-line with clients holding (and bearing) their tokens.
Stateless communication means that you store the session (part of the client state) on the client and send it with each request that requires it. In the case of normal sessions the session is stored on the server and only the session id is sent by the client. In the case of JWT you sign the token, because you don't want the client to modify things like user id in it, but the client stores the session data. This is important because of scalability. When you have a few thousand servers and it is random which server gets the request, then maintaining sessions on server side becomes really hard. Either you make a copy of all the sessions on each server and syncing copies becomes a nightmare or you maintain it on a single server which will crash eventually. So better to keep session data on the client and you solve this issue with a little communication overhead.
This question already has answers here:
How do I authorise an app (web or installed) without user intervention?
(2 answers)
Closed 5 years ago.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground). It's an app to be run only for my account, in headless mode, on a trusted machine, to manage my cluster.
NOTE: must not require any proprietary software installations (e.g. the Google SDK).
Google provides an API Client Library for Java, which itself depends on an OAuth client library.
For the project of 9Cards launcher for Android, within the back-end, we had to use this library to fetch applications usage statistics from Google Analytics. In our code, because it is a case of "server to server" authentication, we use a Service Account's credentials. The code issues a request from Google a short-lived OAuth2 Auth Token. The library may provide similar features if you use a Client-ID and Client-Secret.
Regarding the issue of licenses, the library is published under Apache License v2, so in that regard it is not too proprietary.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
Good start. I guess by "the JSON API endpoints" you mean the Google APIS. Make sure you created OAuth Client IDs and not one of the other options.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
Yes the OAuth Playground will do that for you. The detailed steps and sample code to consume the token is at How do I authorise an app (web or installed) without user intervention? (canonical ?)
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground).
Follow the steps linked to above and you will see that you don't need to write any code at all. Once you have the refresh token (a one time procedure), you're all set. I exaggerate slightly, you do need one line of code to post the refresh token to the Google Oauth endpoint to fetch an access token. See the bottom of the linked answer for an example. Or you could just compose a curl to do it from the command line and put the Access Token into an environment variable.
I just wanted to avoid the whole thing and get a code printed on the screen
A bit like https://youtu.be/hfWe1gPCnzc?t=198
Just found out that the basic workflow for token-based authentication is as follows:
User requests access by providing username and password
The application validates the credentials and returns a token to the client
The token is then stored on the client and sent with every request henceforth
The server then validates the token and returns private data as a response
Now, I understand the flow more or less, however, I'm having issues with the terms application, client and server. I understand the term server to mean where the API is stored... which is also part of the application. But the application could also be anything from a web app to a mobile app on various platforms... a client in other words.
So isn't it true that the application includes both the server and the client. So what does it mean by each term exactly, in the above context?
On second thoughts... I guess the original token is being generated on the server side, and this is then being returned to the client. Is this true?
Those terms terms are pretty overloaded in software development, so it's always difficult to nail down the exact meaning without focusing in a very specific context. Bear in mind that even authentication can be seen as a very broad context.
I would rephrase your proposed workflow to the following:
User requests access by providing a set of user credentials (we don't have to use passwords all the time, see passwordless authentication out of curiosity).
The authorization server validates the user identity and, if valid, issues an access token.
The client application from which the user started the process receives and stores the issued access token.
The client application calls into a resource server using the access token in order to obtain user associated resources.
Damn, now we have even more terms, but let's try to fix that by providing some definitions.
First, the ones more generic:
Client: An application that obtains information from a server for local use.
Credentials: Usernames, passwords, email addresses—any of a variety of means for communicating parties to generate or obtain security tokens.
(source: Auth0 Identity Glossary)
Then definitions within the context of OAuth 2.0 and/or OpenID Connect:
Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
(source: RFC 6749)
It's not even useful trying to define application, but what we should conclude from the other definitions is the following:
As you said, a client can range from web, to mobile to event server-side applications.
The role of the authorization server and resource server can be played by the same component, for example, a Web API that has an endpoint protected by HTTP basic authentication that can be used to exchange a pair of username/password credentials with an access token and then all the remaining API endpoints are protected in such way that only allow access if you provide that access token.
Finally, one final note to clarify your last question, yes, the creation of the access tokens need to happen on the server side because the creation of the token will be accompanied by some kind of mechanism that will ensure that the token cannot be tampered with and was in fact created by a very well-know entity. For the case of JWT's this mechanism consists of signing the token which is accomplished by having the server know a secret that no one else knows.
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 6 years ago.
Improve this question
I have mobile application REST API calls which hits to my server without any token or security mechanisam.
I want to secure my API calls. I am trying to understand what is OAuth and how it will secure my mobile app REST API calls which are hitting to my server?
Also I want to know in details about the below fields which are used in OAuth . From where I will get below fields.
Consumer Key
Consumer Secret
Token
Token Secret
Timestamp
Nonce
Since most of providers use OAuth 2.0 and OAuth 1.0 has been deprecated by major providers, I will explain OAuth2.0
What is OAuth?
OAuth is an open standard for authorization, commonly used as a way for Internet users to log in to third party websites using their Microsoft, Google, Facebook, Twitter, One Network etc. accounts without exposing their password.
you can implement your own OAuth server, here I am explaining about social auth. so the term OAuth here after refers to social auth with OAuth.
In layman's terms, OAuth lets users login to your web service with accounts(Facebook, Google etc).
Terminology:
client: The user of your API.
Resource Owner (api server): Your API
Authorization Server (auth server): Facebook/Google etc auth server.
Authorization grant: the method by which you authorize a user. we are using Authorization code here.
Authorization code: A code that the auth server returns to the client which can be exchanged for an access token at the api server.
Access Token: A string that identifies a user, usually comes with an expiry period.
Consumer Key or APP_ID: a public key used by auth server to identify your application.
Consumer Secret or APP_SECRET: a private key which should be kept confidential.
The below terms have nothing to do with OAuth but are used with OAuth to make it more secure.
Timestamp: a string that tells date and time.
Nonce: a number or string which can be used only once.
source: http://smerity.com/
I will explain the diagram with Facebook login as an example.
Background;
consider you have done the below, before explaining the diagram:
You register an app with Facebook developers portal.
Facebook provides you two codes, 1) a secret_key and 2) an app_id
You designed a button which says Login with Facebook.
Now the diagram:
Client requests the API server.
API server redirects to login page saying. To access the data: please login with facebook to access the page
User clicks on the login with Facbook button, a new popup OAuth dialog opens. asking for facebook username and password.
User enters his username and password, then allow access to your app. auth server redirects the user to your website with a code as parameter in URL.
API Server is called on the step 4, API server captures code from URL.
API server call auth server with the provided client_secret
Auth server returns to the access token for the user to the API Server.
API server asks auth server for user information for the given access token.
Auth Server returns details about user, profile pic, email etc.
API server identifies the user, sends him the response along with access token.
client sends the access token to the api server on next request.
API server checks if access token is valid and respond.
When access token is expired, client is asked to login again.
Now, How does this secure your api?
Make the portions which need security as login required to access them. if the client who makes the request is not logged in to your api, send him to step 2 of the diagram.
So what is nonce? timestamp?
If someone steal an access token, he can get access to API server as long as the access token expires. So when the user requests a page, server sends him back a nonce which is stored in the server. the client signs the request with the recieved nonce and complete the request. as the nonce is only used once, server deletes the nonce. when an attacker grabs the nonce, and make a fake request to the server,server rejects the request as the one time number is invalid as its used already.
TimeStamp is used identify the time the token or nonce is created which is used to expire the token or nonce in a limited time frame (1-2seconds), the time needed for a request to complete.
I am designing a REST API in Laravel to be used with my ios app. Currently I am stuck on the following point: How to secure my REST API to allow access to ONLY my ios app?
I have read about HTTP Basic Authentication, HMAC, oAuth2.
1) Basic authentication requires SSL and it requires you to send the username:password on every api call.
But this doesn't stop others from using the API from other applications assuming they post their login credentials to the endpoints?
2) I understand the HMAC method and how the client & server both know of a Public & Private key. The private key is encrypted along with the request and other data. The public key is sent in the headers. When the server receives the request it detects the public key in the headers and associates it with a private key in the DB. It then recalculates the hash and checks if it matches. So, I have the following questions:
How does a newly registered user get the private key to be stored in the IOS app if the private key is not to be sent over the wire?
Is this more geared towards applications that will utilize your app? I normally see this in a API dashboard like Instagram & Facebook where they give you an app secret key, right?
3) oAuth2 - To me this seems more like allowing people to login to my app utilizing another API. For ex, allowing users to login to my app with FB and allowing my API to utilize Facebooks data? I am not really needing to do this at the moment.
am I misunderstanding this?
It sort of sounds like I need to incorporate something similar to the HMAC method by granting my IOS APP a private key where I store this in my IOS APP code. When a request is ran from within the ios app i pass along a hash with the private key and other data and then when the request is received on the server I detect if the request came from a user within the app by recalculating the hash. I have no idea if this is secure & I would assume it isn't?
What knowledge am I lacking? I am so confused at the moment that writing this question was a big struggle. I will revise it as soon as things become more clear.
1.
You're right, this doesn't prevent non-approved clients.
2.
This isn't really a way to prevent unapproved clients, it's more about verifying that a message isn't tampered with over the wire.
3.
You're understanding oAuth correctly, it's about authenticating clients to use your API in a specific way as well as limiting permissions.
It's not really possible to lock down your API so only a specific client can use it, because there's no way to verify who the client really is. Additionally, any form of authentication or verification done on the client side can eventually be be reverse engineered, and then can be sent to the server as an 'approved' client.
Something like this could be done with a token. The server sends a token the the client, the client performs some known operation on the token, such as salting and hashing, with a known salt and hash operation, then returning the token to prove that the client is a real one.
The problem is, if someone reverse engineers your client, they can determine what that operation is, and then create their own client which authenticates the same way. Any form of client side authentication isn't true security and can't be trusted.
Another way this is broken, is if someone can MiTM your request. The request could be captured and modified before it reaches the server, and there's not really any ways to prevent that from happening aside from using SSL, which can be broken with something like SSLStrip.
Any attempt to prevent a non-approved client is basically security through obscurity, since there isn't a provably secure way to do what you're asking.
The best way to protect your API isn't by limiting which clients can access it, but by making it secure already. Best practices would include forcing SSL, only send the password once and use tokens for authentication from then on, etc.