I'm considering using https://account-d.docusign.com/oauth/userinfo endpoint to verify if the user's access token is valid before calling eSignature API.
However, I have not been able to find any information regarding the rate limits for OAuth calls, only for specific DocuSign APIs.
Are there any rate limits for OAuth calls, specifically for get userInfo, and if so what are they?
There is a limit, but your workflow wouldn't really be recommended as that endpoint is not meant to be used for the purposes of token validation. Couldn't you just call eSig and use retry logic (i.e getting a new token) if you get an unauthorised response? Have a look at our quick start applications for ideas on how to do this.
Related
I am currently writing a social media backend server, which should handle a lot of users.
As authentication mechanism, we want to use Google's & Apple's OIDC Authentication (Sign in with Apple).
Now, as we get a opaque access token, I cant really imagine a performant way to authorize the opaque access token, as we can not decode the token (not jwt token) and we do not know the issuer.
What I thought:
Authorize the access token sequentially one by one. Meaning:
Fetch Google/userinfo from Google
If 401, Fetch Apple/userinfo
This is unperformant, as the processing time is getting bigger, when we add more IDP's
Save the issuer in the DB and fetch the user's issuer always in the authentication step, before fetching the /userinfo endpoint
This is more performant, but it does not feel right, as the webserver has to make a DB call + HTTP call to authorize a request from the client.
Am I missing a method to get this in a performant way?
BTW: The webserver is a node.js application using express.js
Thank you very much in advice!
The key point here is that foreign access tokens are not designed for authorization in your own back end. Instead you need to issue your own tokens when sign in completes.
AUTHORIZATION SERVER (AS)
The most standard solution is for your apps to talk to an AS that you own, and for it to manage the social logins for you. The AS will then issue tokens that you can fully customize.
This will enable you to fully control the scopes and claims your back end uses for authorization, as well as the session times in UIs. Your back end will only ever work with access tokens issued by the AS, regardless of the login method a user selects.
When you need to add a new login method you just change the AS configuration and will not need to change any code in your apps. A good AS will support integrating with many systems, as demonstrated in this summary page.
I want to design a GraphQL API. This API would be used by some browser apps and also open to be used directly for people that want to create their own scripts/generate reports etc. The API would rely on a third party app supporting Oauth Openid Connect (okta) for user and role management. It would be written in Django.
Because JWT is a recommended way of protecting GraphQL APIs and also because OIDC uses JWT tokens. I thought of a simple way, where the API would simply accept the JWT tokens issued by okta. This works, but I see a lot of latency when API is asking okta validate the token (this latency might be smaller in production, because I'm testing on a free trial auth0 instead of production okta). So I think that maybe my API should issue its own JWT tokens. I can think of three strategies here:
Leave it as is – only use the OIDC JWTs.
Introduce a login mutation or a login REST endpoint, that would accept OIDC above and issue JWTs that can be used for all other operations.
As above, but also allow the direct use of okta's JWTs (I'm not sure if I can implement it with Django's auth system, so that if a token is recognised, the OIDC is not called).
Which of these three is the correct (and maybe intended by the OIDC designers) way to protect my API?
JWT token doesn't need to be validated by Okta (generally by IdP). You just need to get used public key (it can be found as jwks url in discovery response) and then can you can verify signatures without any IdP call.
IMHO you can get 2-4k validations/sec easily.
I have an API and that API needs some data from the Microsft Graph API. I was thinking of implementing an endpoint in my API to refresh the token and use that token to make calls from the frontend. I don't know if that's optimal or safe, hence my question.
EDIT 1: To give a better perspective of what I have, this is the logic I have at the moment. Tell me if this is correct please.
User requests my API's authorization endpoint, which has the Azure's secret key, then the user is redirected to the Microsft oAuth login page. Once logged in oAuth, Microsoft redirects the user to my API, where it saves the JWT tokens in the user's cookies, so the user can refresh the token anytime.
In order to refresh the token, the user simply just makes a call to myapi.com/auth/microsoft/token, where it has the secret key, and it refreshes.
Generally I would recommend always making the 3rd party calls from the back end. It gives you more control and avoids any cross origin complications.
You also want to be aware of any API keys. Most APIs require a key for access and often that key is private and you wouldn't want to share on the front end.
MS Azure APIs have an application and secret token. You cannot expose the secret token to the client. To call directly from the client you would use OAuth to get a JWT token and then you can call from the SPA into the MS Web APIs with that token.
https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-scenarios#single-page-application-spa
In contrast, there are other 3rd party APIs that are designed to be called only from the front-end. Stripe for example is a payment processing API where the UI can call directly into Stripe and then the client's payment information is never actually passed to the host application, only to Stripe. This improves security.
I have a simple use case for the instagram api: I want to display media related to a specific tag. E.g. GET/tags/tbt/media/recent. I do not need users to authenticate with Instagram to do this, I merely wish to use my own account and access_token to make the api requests.
Unfortunately, I've run into two problems:
I cannot test this API in sandbox due to the fact that the public_content scope is only available to approved applications.
My app submission was denied because I did not provide a screencast showcasing my usage of an instagram authentication flow (my use case does not have one, and I explained that I did not need users to authenticate).
Currently, the API seems geared towards larger, richer integrations, and doesn't leave a lot of space for applications like my own.
Is there a way to accomplish what I want given the new access_token only flow?
I'm working on building a RESTful API for one of the applications I maintain. We're currently looking to build various things into it that require more controlled access and security. While researching how to go about securing the API, I found a few different opinions on what form to use. I've seen some resources say HTTP-Auth is the way to go, while others prefer API keys, and even others (including the questions I found here on SO) swear by OAuth.
Then, of course, the ones that prefer, say, API keys, say that OAuth is designed for applications getting access on behalf of a user (as I understand it, such as signing into a non-Facebook site using your Facebook account), and not for a user directly accessing resources on a site they've specifically signed up for (such as the official Twitter client accessing the Twitter servers). However, the recommendations for OAuth seem to be even for the most basic of authentication needs.
My question, then, is - assuming it's all done over HTTPS, what are some of the practical differences between the three? When should one be considered over the others?
It depends on your needs. Do you need:
Identity – who claims to be making an API request?
Authentication – are they really who they say they are?
Authorization – are they allowed to do what they are trying to do?
or all three?
If you just need to identify the caller to keep track of volume or number of API Calls, use a simple API Key. Bear in mind that if the user you have issued the API key shares it with someone else, they will be able to call your API as well.
But, if you need Authorization as well, that is you need to provide access only to certain resources based on the caller of the API, then use oAuth.
Here's a good description: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/
API Keys or even Tokens fall into the category of direct Authentication and Authorization mechanisms, as they grant access to exposed resources of the REST APIs. Such direct mechanisms can be used in delegation uses cases.
In order to get access to a resource or a set of resources exposed by REST endpoints, it is needed to check the requestor privileges according to its identity. First step of the workflow is then verifying the identity by authenticating the request; successive step is checking the identity against a set of defined rules to authorizing the level of access (i.e. read, write or read/write). Once the said steps are accomplished, a typical further concern is the allowed rate of request, meaning how many requests per second the requestor is allowed to perform towards the given resource(s).
OAuth (Open Authorization) is a standard protocol for delegated access, often used by major Internet Companies to grant access without providing the password. As clear, OAuth is protocol which fulfils the above mentioned concerns: Authentication and Authorization by providing secure delegated access to server resources on behalf of the resource owner. It is based on access Tokens mechanism which allow to the 3rd party to get access to the resource managed by the server on behalf of the resource owner. For example, ServiceX wants to access John Smith's Google Account on behalf of John, once John has authorized the delegation; ServiceX will be then issued a time-based Token to access the Google Account details, very likely in read access only.
The concept of API Key is very similar to OAuth Token described above. The major difference consists in the absence of delegation: the User directly requests the Key to the service provider for successive programmatic interactions. The case of API Key is time based as well: the Key as the OAuth Token is subject to a time lease, or expiration period.
As additional aspect, the Key as well as the Token may be subject to rate limiting by service contract, i.e. only a given number of requests per second can be served.
To recap, in reality there is no real difference between traditional Authentication and Authorization mechanisms and Key/Token-based versions. The paradigm is slightly different though: instead of keep reusing credentials at each and every interaction between client and server, a support Key/Token is used which makes the overall interaction experience smoother and likely more secure (often, following the JWT standard, Keys and Tokens are digitally signed by the server to avoid crafting).
Direct Authentication and Authorization: Key-based protocols as a variant of the traditional credentials-based versions.
Delegated Authentication and Authorization: like OAuth-based protocols, which in turn uses Tokens, again as a variant of credential-based versions (overall goal is not disclosing the password to any 3rd party).
Both categories use a traditional identity verification workflow for the very first interaction with the server owning the interested resource(s).