I'd like to build an app with a server-side Rails 5 API serving JSON data, and a React or other JS front-end, but I would like users to authenticate with their github accounts.
So when the app starts the user would log in with github and then receive a JWT token to use to interact with the Rails API.
Where are some resources I could use to get started here?
I ended up rolling my own using Faraday and manual api calls.
https://github.com/Ada-Developers-Academy/ada-prs-api/tree/authentication
Currently it's on hold as I'm switching to a React-Firebase framework as it's better supported and seems more scalable.
Related
I am currently in the process of integrating a React Native android app to complete sign in through my Rails API server backend using OAuth2. The current architecture works as follows:
-visit /request_token on the rails server
-redirect to Facebook for Sign In
-facebook redirects to /access_token on the rails server
-Rails server completes authentication, pulling the user data, and generating a JWT
-JWT is used for all local API requests made to the rails server
The goal is to have the React Native app start this process, so it ultimately ends up with the JWT which can be used to pull data from the Rails server. Facebook OAuth is only used as an intermediary to generate these JWT's (and because OAuth is a requirement of the project).
Does anyone have any insight on the best way to go about setting up this relationship? Any help would be appreciated.
We have an existing application on SoundCloud that was created some time ago and set up to use OAuth1. Recently we needed to expand SoundCloud-related functionality and, because of some problems with the old library, had to upgrade to new cocoa-api-wrapper library that uses OAuth2 client.
The problem now is that we cannot access our application with its key/secret because of the different version of OAuth. While it is possible to set up new application and get new key/secret pair, we wouldn't want to lose all the data associated with the current application.
Is there a way to have the same SoundCloud application accessible with both versions of OAuth (OAuth1 is still being used)? If not, what's the best way to handle this situation?
Yes. You can migrate an OAuth1 token to an OAuth2 token by sending a POST request to the following endpoint:
https://api.soundcloud.com/oauth2/token
with the following parameters:
client_id='YOUR_CLIENT_ID'
client_secret='YOUR_CLIENT_SECRET'
grant_type='oauth1_token'
refresh_token='OAUTH1_TOKEN'
The response will contain an OAuth2 token (as well as expires_in, scope, refresh_token).
I have a rails app that stores my user information and data using the Sorcery gem, and I would like to have a chrome extension I am working on, authenticate with my rails app.
I cannot seem to find any references to an API in Sorcery which would allow me to authenticate using my user database from an external source.
How do I expose my sorcery-powered rails app as an oauth server, such that I can store a key, which I can attach to my javascript application when I make an AJAX to my api.
Is it possible to do so, and/or what is the best practice for cross-site authentication? Like how should I store the authenticated user information etc?
i don't know if sorcery supports token authentication.
devise does, and it's really simple:
https://github.com/plataformatec/devise/wiki/How-To:-Simple-Token-Authentication-Example
I'm developing a mobile app that will interact with a rails app that's essentialy a json api. Is it possible to use an external identity provider such as facebook or googleplus to secure the access to my API?
Users will upload a photo to a json rest service but the rails app would only allow the upload if the uses is authenticated with one of those providers.
I've checked omniauth gem but I don't know if that's the path to do it. I don't understand very well how oauth works so I'm trying to know if this would be possible to do.
Regards
Fak
The answer, in part depends on how you're going to provide Identity via the mobile app. The user's authentication, and their identity are de-coupled.
My guess is you're wanting the user to authenticate to the mobile app using the Google/Facebook sdk app side. To do so, you'll need to use that sdk to generate a token, which can then be saved to Rails. The token can then be required as part of each API request - which rails will validate.
The topic is a bit complex to fully describe the flow....but in essence: 1) Create the token on the mobile app using the mobile sdk, 2) save the user and token to Rails/database, 3) as part of every request check the access_token provided.
Since the topic of Oauth and request/identity providers takes some time to understand, I would first watch he following railscasts on securing an API. Once you're done with that one (and understand the concept), you can also watch this railscast.
Hope this helps.
I'm refactoring a monolithic Rails app into a pure JSON API with a Backbone.js front end. Other smartphone app front-ends will be following in the near future, and the possibility of opening up the API to the public has been mooted around the office.
For that reason I thought I'd do the job properly the first time round and secure our REST API with OAuth 2.0, so that every app built on it - including the ones we build in-house, is "just another OAuth client", which would also give us the usual niceties like rate limiting, key revocation and restriction on the resources that can be manipulated for free.
So far I've followed along with the Railscasts episode on the Doorkeeper gem (warning, it's a pro episode) to secure our own API and register our user-facing web app as a client.
Now the interesting part - the original app allowed users to sign in through Facebook, Google, Twitter etc. through the Omniauth gem. As I understand it, OAuth is concerned with authorising clients, not user authentication, so we'll still need the OmniAuth flow we have already.
But:
where should the "Omniauthing" controller live - in the API or the web client?
how should the "Omniauth bit" to authenticate the user be connected to the "OAuth bit"?
Update: the client could either be just a Backbone app, or it could be a Backbone app twinned with a "thin Rails website wrapper" which has no DB of its own but mediates between the Backbone app and the API using ActiveResource. Which has the advantage of letting us deal with "a client that can keep a secret". In this scenario, the "Omniauthing" controller could live in the Rails client app if that's any use.
A similar SO question discussed login only with Facebook, but while the answer was clear in saying there should only be one authorisation server - Facebook - it didn't say anything about feeding the outcome of user authentication to the resource server.