I have a question which i can't seem to figure out from all the googling. I am building a rails app basically an api app. When i give out post request it returns me with an error 'InvalidAuthenticityToken' so i used
skip_before_action :verify_authenticity_token
And after some googling i came to know that it is not recommended to skip this because our app will be vulnerable to CSRF attacks. I am also using doorkeeper gem for my authentication. My question is that even if i have the doorkeeper gem for authentication will my app be still vulnerable to attacks ?
I have also placed this code in my application controller and removed the above code
protect_from_forgery with: :null_session
Is this safe or can someone say how to properly implement this ?
It's good to have CSRF attack protection in your app. In api you can add this token to header and pass it between frontend and backend. I used this guide from pragmatic studio to set it up in my application:
https://pragmaticstudio.com/tutorials/rails-session-cookies-for-api-authentication
However, I have no idea how will it work with doorkeeper (haven't used it).
Related
I've seen a lot of posts recommending using Xamarin.Auth for SSO in Xamarin, but having reviewed a tutorial as well as the GitHub Getting Started wiki (in which says it supports "Authorization Code Flow", but seems to require a secret key from the client to get the auth code, which is not what I'm looking for) and searched the web fruitlessly for "Xamarin.Auth implicit flow", and "Xamarin.Auth authorization code flow", it appears to me that Xamarin Auth supports only Implicit flow, which is less secure than an Authorization Code flow for a native app that is connected to a backend web server application as mine is. Am I correct in understanding that Xamarin.Auth can only support an implicit flow (requiring that the access token be sent to the client, and a client_secret can't be retained server-side and sent server-side as part of the retrieval of the access token), and not an authorization code flow (in which the client would receive only an authorization code, which it would then send to the server, which then would retrieve the access token using a client-secret and possibly a PKCE exchange)?
Furthermore, even flows with other libraries I've seen recommended seem to retrieve the access token to the client - AppAuth supports PKCE, which is a security improvement vs no PKCE, but the posts I see showing examples of it here and here and here still all retrieve the access token on the client. Auth0 is also recommended in some posts I've seen (e.g. here), but the example I see for that here also retrieves the access token on the client.
Is there a reason why sites are not doing this? Is there a sample or API documentation anyone can point me to for a library that does support retrieving only an authorization code client-side in a Xamarin application? (and then separately, server-side, using that to retrieve the access token using a client-secret, not necessarily with the same security library since that would not need to be Xamarin code - this server-side part I feel confident is a pretty standard thing - e.g. as outlined for Auth0 here)?
Xamarin.Auth do support Authorization Code Flow. As you find in the tutorial, Xamarin.Auth's OAuth2Authenticator class has a parameters called 'Client Secret', together with other provided parameters, Xamarin.Auth is capable of handling the Authorization Code exchange part and return the access token directly back to you, it looks like this part didn't happen, but actually it did.
Digging into OAuth2Authenticator source code, method VerifyOAuth2FlowResponseType shows Xamarin.Auth provides both Authorization Code Flow and implicit flow. For more detailed information, you may read the code together with The OAuth 2.0 Authorization Framework
And here is an example for Authorization Code Flow from client side.
I am making a VueJS app with a Laravel backend. I see Laravel has Passport which is used to authenticate/authorize APIs. (Sincerely I have not yet succeeded in integrating Passport. I have not understood where the starting point is. Will post that question separately).
I have done a lot of searching and still have not found the best/easiest way of doing authentication and authorization, and also interface control depending on permission. (I know "best" is subjective but basically means a method that is easy to integrate, understand and use).
Anyone who has been there and used one that worked really well?
I generally use JSON Web Tokens for my web and mobile apps. It's simpler to set up than Oauth and is a better fit for many applications.
Basically, the user sends a POST request containing their authentication details to the appropriate endpoint and receives a token in response. The user can then include that token in the Authorization header of future requests to authenticate them.
The token also includes a timestamp for when it expires, and it can be decoded on the client side so that an application can refresh the token before it expires.
There's an excellent implementation of JWT for Laravel which I use all the time and can highly recommend. There are also client-side libraries for handling JWT with pretty much every framework under the sun.
#MatthewDaly, I followed your recommendation and I stumbled on a VueJs-Laravel JWT implementation here: http://jimfrenette.com/2016/11/laravel-vuejs2-jwt-auth/
I followed through the Tutorial and was able to make it work for my case. (Caveat: The post is slightly old (using Laravel 5.2), but with good understanding of Vue and Laravel, you can be able to follow and implement it easily).
I've setup devise + omniauth for Google sign in. It works great on the web. I'm now looking at integrating the oauth sign in to iOS / Android clients.
I've been following https://developers.google.com/identity/sign-in/ios/backend-auth and found that the library I'm using for oauth does these things (https://github.com/zquestz/omniauth-google-oauth2/blob/master/lib/omniauth/strategies/google_oauth2.rb).
What I'm not clear about is if I can use a omniauth strategy outside the regular web workflow (i.e. from rails console) to build a pseudo request.env["omniauth.auth"]. Is something like that possible? Per the documentation https://developers.google.com/identity/sign-in/ios/backend-auth#using-a-google-api-client-library I'd like to do the equivalent in Ruby (and am unclear if I can use Devise directly to do this).
Simulating requests in the console is pretty easy. You can easily make requests to the app variable the console provides:
app.get('/') # => 200
app.response # => #<ActionDispatch::TestResponse:0x007fc73e4db220>
As for handling authentication, standard rails applications use cookie/session-based authentication strategies on the web. After you authenticate the first time, some information gets stored in session (often as a cookie) that you and the server will pass back and forth with each request.
Since mobile clients don't rely on cookies, we need a different authentication strategy: token-based authentication.
Here a high-level implementation that would work with Omniauth:
User Requests Access through Omniauth proivder by making requests to the Omniauth endpoint
Application processes the credentials
Application provides a signed token to the client
Client stores that token and sends it along with every request
Server verifies token and responds with data
For handling mobile requests, you'll need to be careful to follow the fine print for the provider's Omniauth gem.
Token authentication used to be baked into Devise, but it was removed. Thankfully, there are a few gems that add token auth to Devise:
simple_token_authentication
devise_token_auth
I need to authenticate to JIRA using Okta via REST, how can I do that on ruby? It is possible? I never did that before, I just only want to get an attached file from a ticket in JIRA
It turns out that you can just send the JSESSIONID cookie from a logged-in user (such as yourself) to the REST API. You can get the cookie manually from the browser, or write a browser extension to get the cookie and then invoke your Ruby script with that cookie's value as a command-line argument. For Chrome, you could use Chrome Native Messaging for this.
You should be able to do it by setting up an Application Link to a ruby web application with 2-way OAuth, but this is quite complicated and heavyweight.
I would like to figure out a way to do it with just basic auth and no Application Link, but I haven't figured out how to yet.
I'm currently running into a lot of issues with the CSRF token.
Our current setup is a Ruby API and an Angular front-end, both live on a different domain.
The Ruby back-end solely serves as an API for the front-end.
I've spend a lot of time researching this problem, but I can't find a proper solution.
So far the solutions I've found are:
Generate the token and insert it into the DOM (Different domains, so can't do that)
Let the API return the CSRF token on a GET request (Doesn't seem to work, and it's not a good solution since I don't want to make an extra request just to get the token)
So I'm rather stuck here and not sure how to continue.
Is the current implementation just not working? How do other people create an API with oauth without running into this issue?
Not sure if this will help but here is a sample of a simple todo api in ruby with angular as frontend, and i am using token for authentication generated after the user fills username and password.
https://github.com/sirfilip/todoapi/blob/master/app.rb (the api written in sinatra and sequel)
https://github.com/sirfilip/todoapiclient/blob/master/public/js/angular-todoapi-plugin.js (angular client api service that is used for communication with the api)
TL;DR: Secure your rails API with the doorkeeper gem.
This SO post seems to be the accepted answer when your api and client exist on the same domain.
In the post they outline the angularJS docs http://docs.angularjs.org/api/ng.$http :
Since only JavaScript that runs on your domain could read the cookie,
your server can be assured that the XHR came from JavaScript running
on your domain.
To take advantage of this (CSRF Protection), your server needs to set
a token in a JavaScript readable session cookie called XSRF-TOKEN on
first HTTP GET request. On subsequent non-GET requests the server can
verify that the cookie matches X-XSRF-TOKEN HTTP header
It seems that the security of storing and transferring the XSRF-TOKEN session cookie in this way hinges on having your api and your front-end be in the same domain. Since this is not the case, you may have to implement another form of authorization for any given client session, like OAUTH. I'd recommend taking a look at the doorkeeper gem. The gem will give you the ability to interact with your api as if you were any other client.