We want to integrate into many different APIs so that our users can import their data on other apps into our app or do actions on their other apps when triggered on our app.
Plain API integration.
However, integration process takes too long for many services and you have to fill lots of forms. You have to submit a request to that platform, they check it, then publish in a few weeks or months. Doing this with many different apps can take months.
I just want to delegate the authorization process to another service. For example, https://auth0.com/ can authenticate users on their platform. This way, you can just use Auth0 and users can sign up to your app from hundreds of different apps. I need something similar to that but I need the access token.
Whenever a user wants to integrate another app to our app, I will redirect the user to that intermediary service and it will handle authorization and return us the access token.
Is there a service that can do that? Is this allowed by services like Google or Microsoft?
One platform I found is apideck.com
Handles authorization process instead of you, your users can see which apps they integrated over their panel or widget.
Allows you to quickly connect to tens of api services.
Related
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
I'm developing an ASP.Net MVC 4 Web API application where this application will be the source data for different Mobile/Web client apps. I need to authenticate a user so I can return the correct set of content for the user. I'm thinking about using an API Key that is sent to every request of my Web API application. The API Key identifies the user. I found this post that outlines a potential solution: From API Key to User with ASP.NET Web API
I need to support forms authentication as well as oAuth 2.0 for Facebook, Twitter, etc. All of these approaches yield a token I can use to send back and forth from the different clients to my Web API so I can identify the user. I understand Facebook access tokens expire. I'm a little confused on what's the best way to deal with Facebook interactions. Which of the following paths is the best way to go:
Rely on the different client apps to authenticate against Facebook (and other oAuth providers) to establish a Facebook access token that's then forwarded to my Web API application? This means all of the clients are responsible for making sure the Facebook access token is not expired. The Web API app assumes the access token is always valid. This seems dangerous to me. The different apps would authenticate the user then send user information to WebAPI app to register the user in order for the user to consume the data from my Web API app. This seems like a lot of duplication.
Make my Web API application solely responsible for interacting with Facebook (and other oAuth providers) on behalf of all the different client apps using my Web API. So this approach seems to suggest I need to build some sort of authenticating UI for my Web API app. I know ASP.Net MVC Web API can have views and front end stuff, but it always seems to me that you are mixing things together. It seems Web API apps should be singularly focused on returning data. Users from all of the different client apps will register with my Web Api app by either filling out a registration form, or using Facebook, Twitter, etc. Is it OK to mix UI views in with a pure REST Web API application? Then you have to start worrying about everything that goes with UIs on different devices, etc.
Is there another way I'm not seeing?
I really appreciate any guidance and links to examples you might have. Thanks for your time.
I would suggest you below approach:
1. Create an authentication API which will authenticate the user. If user is authenticated successfully, create a session (self implemented, may be a record in your db) for that user.
2. Next time user call your other APIs which returns content for that user. In this case it would be must for that user to provider the session id (which you have created in first step) to get the content. If sessionId provided by user does not exist at your end, it means the user is not authenticated. In this case you can return authentication error message to the user telling that he needs to get authenticated first. It is very flexible, scaleable solution in a way that you can store many information regarding that user session. Also once authenticated, user does not need to get authenticated every time he calls your other APIs to get content. It would save you as well from authenticating the user every time.
I'm building an application which uses last.fm API. I want my server to communicate with last.fm and the users of my application would communicate with the server. So the user is indirectly communicating with last.fm. I'm doing this to speed up the whole communication by caching some data on my server.
Is this OK?
As long as you follow their TOS, you are OK.
Yes, this is OK. Many other services do this.
If you think about it, any action any app takes is always indirect. There is no requirement that the application acting on behalf of the user runs on the same computer as the user. Quite often the application runs on a web server.
Some examples of apps which do this include http://tweekly.fm/ and http://hypem.com/ .
In order for the service to act on the user's behalf (for certain methods such as scrobbling), you have to authorise your application as the user, and this is achieved using the web auth flow described at http://www.last.fm/api/webauth .
(This is one of those flows where the user is directed to a page on Last.fm to confirm that they authorise your app. Your app receives a session key in return, which allows your app to act on behalf of the user).
I know there is a lot of questions out there already and I've been reading blogs and looking at samples for well over a week and I'm still a little hazy on how some of this is going to work in the real world. The samples are very helpful, some are very complex some are simple, none have really clarified some of my questions.
The system comprises:
Web App (own IIS site, with SSL, consumes Public API)
Public API (own IIS site, with SSL)
Desktop Widget
Mobile (iOS, Android)
3rd Party apps
How best to handle user registration and account creation? Whilst offering OpenID there also needs to be a 'local' login to the web application. Having a method on the API that accepts base data types (strings/dates etc...) values and then creates an account is asking for trouble and a red flag to the spammers. Would it be best to handle this exclusively through the web site employing visual CAPTCHA checks? How does the Facebook mobile app handle this registration scenario?
Lots of samples also seem to use small subsets of the default Forms Authentication database for Membership. They then use Entity Framework and the Membership, WebSecurity or FormsAuthentication, Roles Provider classes in various different ways depending on use case. Are there any alternatives to this approach to consider for the security backend? Our DB guy is considering rolling our own but then we also need to build our own user management app :(
Once a user is registered and logged in to the web app I can't see any way around continuing to authenticate and authorize each call on the WebAPI. I'm assuming at the moment that the API should just implement OAuth and treat the web app as another client app like the mobile app and 3rd party apps.
I think I've read too much without playing with code to settle this in my head. There are so many approaches.
TIA,
I am starting a new web project and I intend to make it API based; that is I want to build the API first, authenticated via OAuth, then build a website and possibly mobile app(s) that use the API to handle data. I also have my eye on opening up the API to the public.
Here is my issue; I am struggling to get my head around how to authenticate these 'official' apps, the ones made by me, including the main site.
In OAuth the client creates an account for each user then seeks access rights via the resource owner logging in at the main site. This obviously does not work for me because the main site and the client are the same place and it also implies my users should be creating two accounts just to use my website...
I believe twitter uses its own API to run twitter.com and I get the impression that this approach is becoming quite normal so there must be a standard approach.
I must be missing something, but what?
You are confusing the API (business logic) with the authenticaton of user identity (for example logging in), and the authorization of third party apps (OAuth).
It is correct that twitter.com uses their own API. But they don't use OAuth on their own site. When you're on twitter.com, their APIs are available to themselves over cookie authentication. To put it simply: you're logged in.
Once you move away from twitter.com you have to use OAuth. Now an application is using the API on behalf of a user.
To sum up. You don't specifically need OAuth for your "own" web client to use your own APIs. You need OAuth, or some other authorization mechanism, to publish your APIs and it will also come in handy for your own "official" apps.
There is really no need to distinguish your own official apps from third party apps. Not from a technological perspective anyway.
Host two versions of the "API". One mapped to the external domain api.yoursite.com and it OAuth-enabled to authenticate all requests. The other internal version is accessible only within your pool of servers, your official apps. Since only your official apps can access it in the first place, consider all requests to the internal API trusted.
If you want the same application to manage both external and internal calls, you can choose to
distinguish external and internal requests based on incoming IP addresses
implement your API to accept one of "VIP passes" or OAuth tokens for authentications. External apps use OAuth tokens to perform actions on behalf of certain users. Official apps use "VIP passes" to perform actions on behalf of any user.