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).
Related
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.
We implemented an application which is onboarded in the C8Y server : DM (Device Management) application.
The end user connects to the tenant-related C8Y server and selects the DM application.
The DM application consists of two parts :
Front end (html, javascript)
Back end (Java-spring boot which exposes a rest api). The back end communicates with our custom IoT product.
the backend of our DM application is today located in MZ but can be hosted in DMZ.
Issue description :
The front end (javascript) of the DM application cannot communicate with the backend part of the DM application as the client security requirements :
Does not allow us to set up a http proxy in the DMZ.
Does not allow us to hard code the rest api user (and pwd) in the javascript
Solution (My suggestion) :
When the end user logs in into the C8Y server, We think C8Y server validates the user which is stored in a C8Y database.
We suggests to use the same user credentials(authentication) - which has been used to login in the C8Y portal - to access this rest api.
Then, the back end of the DM application needs to validate this rest api user, by this way the DM application can also validate the user by a single login for the whole C8Y application.
To implement this solution:
We need :
to get the username/password in the frontend.
Or we need the authenticated token in the frontend if any.
We need to know the API that C8Y uses to validate the user from the backend.
Need support to register this as an micro-service where authentication is taken care by C8Y.
Questions:
What do you think about the suggestion to solve the issue?
And also there is one micro-service already registered to the account, so how can we add another micro-service.
In case if there is no support for multiple micro-services, kindly suggest us an work around to let this DM application run as a second micro-service as this is very critical and an blocker issue for our customer.
please check this (new) documenation: http://www.cumulocity.com/guides/concepts/applications/ . I hope that should answer some of your questions.
In detail:
Yes, you can register multiple microservices.
Authentication is handled automatically by Cumulocity, i.e. requests send /service/yourMS are authenticated by Cumulocity and then forwarded to the microservice.
BR, Stefan
I have been doing a lot of research into how to authenticate mobile apps with an API - I still feel a bit unsure about which flow & architecture would be better to use in my particular use case.
I think what's confusing me is some of the terminology used.
My use case:
An API & database on one server. Which holds the users & and the users resources.
A web app, which I have built and consumes the API. Hosted on the same server as the API. So it's dogfooding.
A web app, which I have built and consumes the API. Hosted on a different server to the API.
A mobile app, which I have built and consumes the API.
I'd like to be able to authenticate with the API using username & password.
The API will never be opened up for consumption by other 3rd party services except the web app and the mobile app.
Initially I felt like using the Resource Owner Password Credentials Grant flow would be sufficient. However in the docs it states that this flow should be used if "The client is absolutely trusted with the user credentials".
Since both my mobile & web apps will be built by me, I'm assuming they are seen as 1st party clients. Therefore am I right in thinking they are considered to be trusted with the user credentials? As I typically thought that when implementing oAuth, the idea would be to have the authentication server separate from the resource server. Which would allow you to have one authentication server for multiple APIs.
After reading this post: Why the Password Grant is not suitable for modern applications
It threw me off track a bit. But then, is this post talking about using this flow in my use case?
I was also looking at the Implicit Grant Tokens flow. However using this flow I couldn't really see how the user would enter their credentials first?
I also question if any of the oAuth flows is really needed for my use case and I should instead look at other ways of authenticating?
I'm really quite lost with this I would like some direction to go in with how to authenticate users in my particular case.
Thanks in advance!
I'll most likely be using Laravel to house my API and so I do have Passport available to me to implement oAuth
EDIT
From following this oauth article I've found that in all use cases of my app, I end at Password Credentials Grant flow. Would I be correct here?
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 recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.