We are creating mobile support for our ruby on rails website, and ran into the problems of handling authenticity tokens.
As previous articles have mentioned, authenticity tokens are created on the rails server when a form is created then placed on a form page to prevent tampering.
Understanding the Rails Authenticity Token
Now we can handle the requests from a mobile phone by disabling the csrf
protect_from_forgery
My question is what is the best way of secure external mobile post interfaces to our ruby on rails instance?
You could use OAuth. The app would present the server with a key and secret, that the server could validate. In response, the server gives the app a token. All subsequent requests made by the client must include the token in an Authentication header.
This would ensure, that only authorized clients access your server. And to be authorized, a client would have to acquire a token using a known-only-to-the-client-and-server key and secret.
I am sure there are other solutions too, but you get the idea.
Related
I'm building a REST API using Elixir's Phoenix framework. In the API, I need to authenticate the user by phone number i.e., via sending an SMS OTP code. After authenticating the user, the Auth server sends the Access token and Refresh token to the client. The client(mobile app) stores those tokens locally and sends the Access token in the HTTP header as Authorization: Bearer <Access_Token> in every request to resource server. My actual question is, how do resource server validates the Access token that is received from the mobile app/client?
Does resource server needs to contact Auth server to validate the Access Token? That would a lot of overhead. Please help me understand RestFull API Authentication.
Thanks for taking the time to read my question.
It sounds like you have everything working up to validating the token. You are going to need the public key for the server that signed the token. It depends on what auth server you're working with on how you get that. In some cases you may be able to preload this key as a configuration setting on your backend. Otherwise you can probably get it via https request to the auth server. Most auth servers these days I expect to provide a JWKS api that you can use to get the keys you need. Then with the token and the public key you can use your elixir jwt library to validate that the token you have was signed by the server you trust, meaning the SMS code was validated, and you can proceed with whatever is needed in the backend to handle the request.
If you're using Joken for elixir you can review https://hexdocs.pm/joken_jwks/introduction.html and https://hexdocs.pm/joken/introduction.html for more information.
how do resource server validates the Access token that is received from the mobile app/client?
The same way a nightclub bouncer verifies your driving license as proof-of-age to let you in: by validating the authority and signatures, but it does not need to phone-up your DMV to verify that your license is real because it trusts the signatures (in this case, cryptographic signatures).
That said, some systems do use "reference tokens" which are short (say 32 bytes) of meaningless random data which are used as an unpredictable record identifier for some user-permissions record held by the authorization server. The resource-server will need to contact the auth server initially, but then it can simply cache the auth result itself for some time window.
We are looking into integrating keycloak to protect a front end AngularJS application which is served by a nodeJS application and also makes API requests to this server.
Having watched some tutorials, we see we need to use the javascript adapter for the AngularJS app to handle the user auth flow, and then protect our nodeJS application using the bearer only strategy, ensuring angularJS outgoing requests to our Node application contains an Auth header with the bearer token value present.
I have a question\concern about the way in which the token is being served back to the client as I can see it gets saved into a cookie which I assume is what the javascript adapter reads from in order for us to be able to write the Auth header into subsequent requests from the angular app.
My question is can this token value be easily read from the browser cookie and used maliciously by an attacker trying to make api requests?
Am I right in thinking it would be highly unlikely since the attacker would need to know the secret which is stored on the nodeJS side?
You don't need to know the client secret to use access token. That secret is used only to issue access token. If someone has your unexpired access token, then that someone will be able to use your identity until token expires. But you can minimise the possibility of the stolen access token by using https, httponly cookies. Also, you can use a short token lifetime (for example 5 minute). But then you will need to implement refresh tokens; otherwise, the user will need to re-login whenever access token expires.
I think the proper implementation is not trivial. I recommend using of some reverse auth-proxy, which will handle authorization and authentification in front of your app. Tip: https://github.com/gambol99/keycloak-proxy
I have a MEAN stack web app and I use REST API to connect to the database.
My question is how can I protect it from unwanted http requests?
I already use token verification (JWT) before accessing the database but if the attacker has a token (all he needs is to register to the web app) then he'll be able to access it.
Thanks
I am creating a solution that will contains a website and mobile apps. I will use Zend-Framework 2 for the website.
So, to make it good, I am wondering if it would be a good idea to build :
A REST web service (using zf2)
Another website that will call the REST ws (using zf2)
The mobile apps that will call the REST ws
I will use OAuth for the autentication and security.
My question is, if my website gets the data by calling the REST ws, it will have to make a database request at each call to check the token whereas if I do a "normal" website, my app will be able to use session to store the information of the connected user.
Because, for what I have read, there is no such thing as session with OAuth/REST so for each call, I have one more sql request to check the token validity.
Is it still a good idea to make a full REST service, even for the website or to have a "normal" website and also a REST service API just for the mobile apps ?
Thanks
Oauth is a server to server authentication framework. Like it is between mobile app and your API server , website vs your API server etc. You can adopt an approach where , you generate only one access token for your website client instead of multiple access token for each user from the website. This access token is stored in your webserver vs user cookie in website.Ultimately the aim is to identify all the clients of your REST WS and your website is one of its client and a very trusted one.
This way you can cache the access token to avoid db calls (typically cache time can be equal to or less than token expiry time). Do explore the multiple grant types specified in the oauth spec for this
Regarding maintaining session for user in your website, it is not dependent on whether the back end is a REST WS or not, it can be handled in your website
When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.
So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...
This is not managed by OAuth2 ? Or I missed something ?
For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.
There's no good answer. Native app callbacks typically happen via custom registered URI schemes (e.g.: callback redirection URI is something like: myapp://oauth?code=xyz123). Unfortunately, any app can claim ownership of a given protocol scheme and receive the callback.
This problem is very synonymous with trying to lock down any protocol with "trusted clients". Think of the IM networks battle to lock out 3rd party clients (in early 2000's). Eventually they gave up - since whatever client & protocol endpoints are deployed could be reverse engineered by 3rd party developers.
Note: There is also some active discussion on this topic on the OAuth WG mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html
Normally client_id is associated with site's URL - OAuth responses/redirects will be sent only to the registrated Url. So attacker will not be able to receive results of the request on own site (unless somehow your and attacker pages are on the same domain).