Background: I'm trying to use social oath providers to sign up and sign in on an iOS app. I believe MVC's API is the right way of doing this, but I have a few holes.
The MVC API has a GET /Account/ExternalLogin API call that returns valid external login providers, (often social) login options.
How should I use this from iOS?
Additional parts to this question:
I'm not familiar with the x-auth-token header but I think I'll need to use this in combination with the JSON payload itself. How do I use this?
Buried in the payload is a double encoded URL that I can use with something like GTM oAuth. Is this something I need to decode twice before I use it?
GTM oAuth library looks like a candidate library to use to help out.
Is ExternalLogins the right place to start? If I try and login from the app then the app needs to know client secrets and the like. Shouldn't these be managed safely in the API?
I'm happy to refine this question if it's not up to scratch before you reject it.
Thanks!
Related
My company is wanting to implement OpenID Connect via Oauth 2.0 across our client software, which comes in Windows, HTML5, Android, IOS, etc. Toward that end, we are trying to find a way of getting the login info back that will work across these platforms.
Our understanding was that a custom uri scheme (i.e., companyname://) was the recommended way of going forward, and we have verified on our end that that would work. However, we have yet to be able to find a provider that would support that configuration. So far OneLogin & Google are both locked to https:// (or http:// for dev), which leaves us something of a conundrum.
So essentially, my question is, were we misled about the custom uri scheme? If so, is there another method we can use that will allow our web & standalone apps to pick up the return info from whichever OpenID providers we go with? We want to keep it open as possible, so we're trying to avoid lock-in APIs and suchlike. Any advice would be appreciated. Thanks.
We do support the custom URI redirect. You'll need to select right type of client when creating a client id on Google developer console.
See the details here.
https://developers.google.com/identity/protocols/OAuth2InstalledApp
One way to support any provider is that you use a Web flow to redirect to a page on your site and then your website does a redirect to a custom scheme.
I would like to know if One Drive supports those four ways of Authorization. Please refer to this link. https://www.rfc-editor.org/rfc/rfc6749#page-23
We are integrating our DVR and NVR with One Drive now and we need to understand which authorization method One Drive supports. We are trying to use OneDrive with embedded ARM processors, so the user does not have access to a browser as they would for a web-app.
Please kindly advise how we should proceed from here. Thanks for your time and I look forward to hearing from you.
Best Wishes,
Ted Yang
I am going to say yes, OneDrive probably supports those ways of authorization, because on their authentication documentations page they say the following:
The OneDrive API uses the standard OAuth 2.0 authentication scheme to authenticate users and generate access tokens.
That link takes us to the oauth.net site page for OAuth 2.0. On that page, we find the following:
The final version of the spec can be found at https://www.rfc-editor.org/rfc/rfc6749
which is the document you linked. The OneDrive API documentation says it supports OAuth 2.0, and your linking the definition of OAuth 2.0, so I think it's safe to say it's supported. How to use it is another question entirely, and one I am unable to answer.
I will note, however, that on the OAuth page, they have this to say about it's uses (emphasis mine):
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
I would presume that living room devices could include DVRs, and although your DVRs are for security purposes, the development of cloud storage APIs for either would undoubtedly be similar. So I would say this is probably quite possible.
How to do it:
First things first, you'll need to register your app. This gets you a client id and a client secret which you'll need. Registration directions
There are two methods: token flow and code flow. Token flow is two steps, and code flow is three steps. However token flow uses tokens that expire, so it would require the user to reenter thigns periodically. You therefor want to use code flow. Here's some directions for that.
Basically the steps of the code flow are:
Get an authorization code
User authorization code to get an access token
User access token to make API calls
You WILL need to make HTTP requests. I'm sure you should be able to do this with ARM embedded C. However, step 1 is what gives you to the Microsoft account login page. I am note sure how to circumvent this, exactly. I'm not sure you're supposed to be ABLE to circumvent this, since Microsoft doesn't want you handling their customers' passwords.
They have an example in Javascript that might give useful details on oauth in the oauth.js file. Javascript sample project
It's now trivial to create a web app that sits atop Parse.com. Now that I have this webapp, I want to expose parts of it to other developers via an oauth accesible api. So, they can develop an app that lets my site users 'give them permission' via oauth and they can now access the api.
How would I start going about doing this?
Update: After #Mubix response, I felt the following clarification would help
Currently I am accessing Parse from the server via a REST api, to get around any javascript security issues re:api keys etc. So, the api would be served of a server other than Parse. Also, the server code is in javascript / nodejs. I came across https://github.com/jaredhanson/oauth2orize which seems a likely candidate, was wondering how others are doing it and if anyone has actually gone a further step and integrated Parse access.
Hmmm .. Intereesting question!
Legal:
First of all their ToS doesn't seem to prohibit what you are trying to do but you should read it carefully before you start.
Implementation:
While parse doesn't provide feature to build your own APIs you could implement something yourself. You could treat the third party developers as users of your app. And you can use the ACL to control access.
Problems:
I don't see any way to implement oAuth entirely within parse.
How will third party apps access your API? Ideally you would like them to use a REST interface but with the parse.com REST API you won't be able to manage access to different parts of your data.
Conclusion:
It seems like too much trouble to implement the API entirely within parse. I would suggest that you write a thin API layer that takes care of auth and uses parse as the backend. You can use one of the service side libraries available for parse. eg. PHP Library, Node Parse.
I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
I am building a RESTFul API and wondering what's the best way to do auth? Users will need to authenticate. I know of three ways:
1.) Pass API key in every RESTFul requests:
http://api.mydomain.com/api-key-here/get-users
This is nice because developers can immediately start using the API by simply copying URL string into the browser. Are there any potential security risks though?
2.) Every request passes the API key in the header of the request.
This seems to be more secure, but developers can't make requests via their browser. CURL is required.
3.) oAuth
I must admit I don't know much about it, but seems very popular. My concern is that its a barrier for developers to start using the API. They first must be familiar with oAuth, and have it setup.
Thoughts? Thanks greatly.
If your concern is burdening developers with a high cost to entry, I suggest basic auth, but running your API over https.
I do this with Diligent Street and it works really well. I use an API Key and couple it with a Secret as the username/password combination for basic auth.
I have employed the technique found here: Build a RESTful API. This solution uses an MD5 hash of your API ID, API secret and the UNIX Time stamp and passed in the HTTP header. This authentication method is the same used by Mashery’s Authentication.
This link references and contains a full blown starter kit for creating an API that has Auth, Membership and*API Usage Metering* along with a supporting EF database.
As for testing the service you can use RESTClient to execute HTTP calls with custom headers instead of using Curl.