I want to build a REST API on a server. Say api.xyz.com, which will contain a jwt based user authentication system. I want to build different clients. Say one for android and one for a web app. How do I prevent other people to use my routes in their clients ? Is there any way ? Should I change my design principle to achieve this ?
You can do that by sharing an authentication cookie between the main domain and the API sub domain if it concerns a web site.
A common way to solve this problem when it comes to apps, is using an token based authenication system, like OAuth, which is currently at version 2.
Related
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 need to create a web api with net.core for a mobile (Ionic) app.
Part of this app, do not need be authenticated to see a list of products.
My problem is:
I need to create a web api, to list this products but, the user do not need to login on app, but I´d like that my application could consume this api and not be open to all (just my app can consume).
It is possible? If yes, what I need to do?
Thanks
The only way you can do make the API available to your application without exposing it to the world sans auth, is to keep it internal, i.e. on the same LAN as your website and behind a firewall. This is generally the preferred approach, anyways, if it's not for public consumption as if it's public at all, there's always some potential for breach, whether authentication is required or not.
The one downside to this approach, though, is that you cannot utilize then for any external communication - things like AJAX or in your scenario a mobile application. As a result, if you need to be able to access it via mobile apps, you cannot implement it this way, which then means you must implement an authentication layer to protect it. There is no other alternative.
You can also do a kind of hybrid approach, as well. If there's certain API endpoints that should never be accessed publicly, you can split your API app up into external and internal portions and then keep the internal stuff internal, only exposing the APIs that are absolutely necessary for mobile app functionality. Again, though, for anything that is public, you'll need to implement an authentication layer or it will be wide open.
That said, the authentication doesn't have to be end-user authentication. You just need to authorize your mobile application as a client. Typically, you'd do that via client secret auth, where the application is given a client id and a secret. The client submits that to an auth endpoint and gets back a token. That token is then passed in the Authorization header for requests that require it. All that remains seamless to your end-user, requiring no actual physical login on their part.
I have :
a backend app, done with sails.js.
a mobile application, done with ionic framework.
I would like to accomplish :
give to the users, on my login page, the opportunity to sign-up/sign-in with facebook, twitter, google, and "local".
on my server, I'd like to have a single collection of users, registred, with both local users and provider-authenticated users.
My primary goal, through this question, is to understand the multiple strategies and concerns of provider-authentication inside SPA (be a web app or a native mobile app). I've read many things about 0Auth, OpenID, client-side auth vs server-side auth, session based auth vs token based auth... I just don't get it. There is too much information out there about this and I'm pretty lost.
What are the possible flows ?
I think I got that I can authenticate with both OpenID and 0Auth, but which one should I use ?
On mobile, can I authenticate with "the facebook app" instead of using a web endpoint ?
I usually hear about "callbacks" after auth, what about them in a mobile app, where there is no web-server ?
NB: I'm not directly looking for implementations or libraries (like passport or sails-auth). I'm looking for an explainations of the different approaches and flows. Though, I'm open to discover some libraries as examples of the words
Updated based on questions from #user18044 below
If a user is authenticated in two different web applications via 2 different SAML-based identity providers, and one of the applications needs to request data from a web API exposed by the other application, would it be possible to call the web API methods securely by virtue of the user's current authenticated status in both applications without separately securing the API methods via an API level authentication protocol such as OAUTH? Note that both applications are owned and operated by my company and share the same 2nd level domains and user base, even though the identity servers are different (one is legacy).
Some further information: Application A is a portal application that is going to host widgets using data supplied from Application B. Application A will only communicate with application B via a web API exposed by application B. Currently application B does not expose a web API (except internally to the application itself). This is new functionality that will need to be added to application B. Application A will use Okta as its SSO. Our lead architect's proposal is to continue to use a custom legacy IDP server that we developed internally based around using the dk.nita.saml20 DLL. They are both SAML based I believe, but I don't think they could share the same identity token without some retrofitting. But this is hitting the limits of my knowledge on the topic of authentication. :) I think our architect's plan was to have the user authenticate separately using the two different identity providers and then only secure the web API using CORS, his reasoning being that since the user is already known and authenticated to use application B, that there wouldn't be any security implications in allowing application A to call application B's web api methods, as the user should be authenticated in application B. This seems quirky to me, in that I can imagine a lot of browser redirects happening that might not be transparent to the user, but other than that, I'm just trying to figure out where the security holes might lie, because it feels to me that there would be some.
I know that this approach would not be considered a best practice, however with that being said, I really want to understand why not. Are there security implications? Would it even work? And if so, are there any "gotchas" or things to consider during implementation?
To reiterate, our lead architect is proposing this solution, and it is failing my gut check, but I don't know enough on the topic to be able to justify my position or else to feel comfortable enough to accept his. Hoping some security experts out there could enlighten me.
It's hard to answer without knowing more on how your current applications and APIs are secured exactly. Do the web application and its API have the same relying party identifier (i.e. can the same token be used to authenticate against both)?
If both web applications use the WS-Federation protocol to authenticate users, then most likely the SAML token will be stored in cookies that were set when the identity provider posted the token back to the application.
You do not have access to these cookies from JavaScript. If the web API that belongs to application B uses the same cookie based authentication mechanism, you could use this provided you allow for cross origin resource sharing.
If your web API uses something like a bearer token authentication scheme (like OAuth) or has a different relying party id in the STS, this would obviously not work.
I think the reason this fails your gut check is because you are basically accessing the web API in a way a cross-site request forgery attack would do it.
A problem I see with this approach is that if the user is not authenticated with the other web application, then the call to your API will also fail.
I agree with user18044 as far as it being based on a cross-site request forgery attack and the security between applications. Is it true that if User X has access to App A, that they will have access to App B and vice versa? If that is not the case, then each application will need to be authenticated separately...and it won't be a SSO. I found these links that might be helpful in your situation.
https://stackoverflow.com/questions/5583460/how-to-implement-secure-single-sign-on-across-various-web-apps
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations
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.