I have a Node.js REST API which is usually consumed with a valid token after login from UI . The token generation and authentication happens on my node.js server only. I have to secure this API for programatic access.
For example, an "Add item to an inventory API". The API should allow adding item after a merchant logs in through the UI as well as through programmatic access from his end (Assume he has an automatic system which enables him to be able to do so periodically)
How do I secure such a system properly. I have few solutions in my mind to implement
this but what would be the most right way to do this ?
It sounds like you want to provide your merchant an API key in order to access your app's APIs. It's a very common pattern.
Related
I am going to build a web application that allows users to sign in with their Google or Twitter account. I think OpenID Connect(OAuth2) is the standard today to verify the identity.
I also want to provide several API services that can be only accessed with a valid access token from either Google or Twitter.
For example, all the four API's above are going to be public and so I have to protect from unauthorized users. For NodeJS based API services I can use http://www.passportjs.org/ to protect all APIs.
Assume, in the future the number of API's will be grow for example up to 20 API's and sign in with Facebook account will be also allowed.
Again, all the API's have to be protected and I have to do it 16 times with http://www.passportjs.org/.
In addition add the new provider Facebook, I have to do the changes on all 20 APIs.
The question is, is their a way to keep centralized, which means in the future when I will provide more the providers for example GITHUB for sign in I would like to do changes in one place not in 20 places.
Is the tool https://www.ory.sh/hydra what I need?
These are perhaps the two primary features of OAuth 2.0 and Open ID Connect:
Federated sign in to your UIs via multiple identity providers and the ability to easily add new options such as GitHub in a centralised manner
Full control over claims included in access tokens, so that your APIs can authorize requests however you'd like
FOREIGN ACCESS TOKENS
You should aim to avoid ever using these in your apps. Your UIs and APIs should only use tokens issued by your own Authorization Server (Ory Hydra), which manages the connection to the Identity Provider. Adding a new sign in method will then just involve centralised configuration changes, with zero code changes in either UIs or APIs.
IF YOU DON'T HAVE AN AUTHORIZATION SERVER YET
Maybe have a look at the Curity Identity Server and its free community edition - use sign in with GitHub, which has strong support for both of these areas:
Many Authenticators
Many Options for Issuing Claims
EXTERNAL RESOURCES
One exception to the above is that your APIs may occasionally need to access a user's Google resources after login, by calling Google APIs. This would require the token issued by Google. It can be managed via an embedded token approach - though it doesn't sounds like you need that right now.
I am developing an api that will be eventually behind a paywall - In my scenario, clients would sign up, pay for an api tier/plan and afterwards be able to consume that api from their own apps. Depending on the tier chosen they will have certain usage limits on the api ( e.g. throttling/limits and various apis available depending on tier)
I was thinking of distributing an api_key for ease of use by clients but not sure if thats a good idea or how it would fit in with the Jhipster security model.
I guess I can just have clients sign in to grab JWT access/refresh tokens but that makes things a bit more complex for prospective clients.
Is the answer to go 'full Oauth2' and create separate 'App Clients' of an Okta Authentication server and give each customer their own "clientId + secret" that they can use to obtain access tokens ?
Any advice ?
thank you
I think it would be easy for you to go with jhipster UAA server which It serves as:
An OAuth2 Authorization Server, based on Spring Boot's implementation
An Identity Management Server, exposing a user account CRUD API
it is easy to integrate with your already jhipster tech stack and it is based on OAuth2 standard.
but for the metric and limitation part you’ll need some coding and a separate fast and high available storage to keep track of the usage of API's and a file provided to your HAproxy as a blacklist for people who reached their limit to be redirected to purchase page.
I'm working on a submission for a conference. I'd like to integrate DocuSign with Alfresco's Angular based developer framework and specifically the Alfresco Content App.
In order to keep things simple, I'd like to think about workflows that could be done 100% from the browser without any backend code of my own.
I suspect I could create a "Sign this document now" type action for any document found in the Alfresco UI. That could initiate an OAuth flow that would not require any backend services of my own.
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Are there other use cases I can implement in an SPA without adding backend services of my own? Things like, sending a doc out to be signed by one or more people? Or embedding a signing experience in the Angular UI?
I have seen the following series on the DocuSign blog:
https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-1/
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
I also have not found any place online where I can reach out to a developer evangelist from DocuSign to discuss my options. I believe DocuSign developers monitor SO, so figured this was the next best thing.
Great question. Browsers implement the Same Origin Policy. So, as I wrote in the blog series (see all three of my posts listed below), you will need a CORS gateway to make API calls from your Angular program running in the browser itself to the DocuSign system.
The good news is that creating a private CORS gateway isn't hard. See part 2 of the series:
Part 1. Introduction
Part 2. Building a private CORS gateway
Part 3. An example React SPA
Authentication
Your app will need an access token when it makes API calls to DocuSign. There are multiple techniques available to give your app the access token it needs:
Your app can, by itself, authenticate the user with DocuSign. In this case, because of the security issues--as you mentioned in your question--you do not use the OAuth Authorization Code Grant flow. Instead, you use the OAuth Implict Grant flow, which is designed for this use case. This flow is demonstrated in part 3 of the blog series.
You can implement the OAuth Authorization Code Grant flow in your server, and then create a private API between your server and your browser app to obtain the access token.
A private API
As an alternative to using CORS, you can just implement your own private versions of the DocuSign API methods on your server. Then your browser app would send a private_send_envelope request to your server. Your server would manage the access token, send the request to DocuSign, and relay the response back to your browser app.
This pattern is the same as your question about implementing a backend service. It will work fine but is not as elegant as implementing everything within your browser app. Depending on your immediate and future API needs by your SPA, this might be a good idea or not.
CORS support is the key
Until DocuSign has CORS support you'll need to build something on the backend. Either a CORS gateway (which only involves configuration, not software) or a private API gateway.
Please ask your DocuSign sales or technical contact to add your information to the internal DocuSign proposal for CORS support, PORTFOLIO-1100. This will help raise the priority of CORS support. Thanks.
Specific answers
Regarding:
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Answer: It is okay to add your integrator key (IK) to your browser app if and only if the IK is set for Implicit Grant usage (check the "Mobile App" checkbox on the IK's property sheet).
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
Answer: at this time you will either need to implement a private CORS gateway or implement backend software.
I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
I am using Nodejs,expressjs,and mongoose to develop a application.Now what is procedure or way to identify that the request hit of my rest api service is from my front end application not from any unknown request.
If your front end application is a browser web page, then there is no real way to limit your REST API service to only your web app.
The issue is that by its very nature the REST API service is available on the web to any client that wants to access it. You could add some authentication (some sort of secret key) that is required before the REST API service can be accessed, but you cannot hide that secret key in a browser web page. If the browser web page can get access to the key, then so can anyone else who looks at the code in the web page or on the wire.
Because browsers, by default, will not allow cross origin Ajax calls, you are already protected from some other web pages (on a different site) using your REST API service from the browser. But, other servers can still use your REST API service.
One common way that services attempt to manage the use of their APIs is that they require an API key be obtained for each legitimate use of the API. If a particular API key is found to be abusing the service, you can revoke the privileges of that API key. You can grant your own applications API keys (embedded in your web pages ) and you can even change those web keys regular (such as daily) to keep people from copying them once and then using them for a long time. But a determined hacker will still find a working API key and use it for awhile.
One common way that services attempt to prevent excess usage of their API and protect the integrity of their service is to implement rate limiting. You establish what you think is a reasonable number of API calls per second (or some such metric) that your own app would not exceed and you measure the number of API calls coming from each endpoint and if they exceed some threshold, then you either delay or deny or error their calls until they stop exceeding your threshold.