I'm using OneLogin's Java SDK/Client to retrieve Events, Users, Groups and User Roles data.
I'm wondering if there is a URL length limit because the REST API endpoints to get data are invoked using HTTP GET method.
I don't think you gonna have problems with the queries you build.
OneLogin supports SAML, and the SAML Messages length is kinda big.
Related
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.
I'm trying to accomplish the following scenario.
I have and API at the moment and one web app. I have also create a new oauth client on my auth server (keycloak), which follows the implicit grant. I also used jwks on my nodejs api to do the token verification.
Now I want to create an SDK that will target the same API.
The questions is how do I get the SDK to retrieve an access token from the auth server. The first thought is that I will have to create a new client oauth client on the authserver and then use the client credential flow to get the access token. However, I dont know what should the behaviour of my API be like. At the moment it used jwks against a single audience. How should it be configured to verify access tokens from multiple clients (potentially thousand of them)
If you want multiple clients to call your API they should all use the same audience, and your first level of security will work.
The audience in access tokens represents the API(s) the token can be used against.
You will then need to use something else to authorize API requests, depending on the type of client and what they are allowed to do.
Configure each type of client in your auth server so that you are in control and know who is calling the API.
You may have 1000 clients but only 4 levels of privilege - in which case only configuring 4 OAuth clients may make sense.
One OAuth option you can use is give different clients different scopes. Scopes can represent high level privileges.
If a particular client calls an addOrder operation but does not have an Orders scope you could return a 403 response.
Often though API authorization needs to go beyond OAuth checks and apply custom rules based on the end user privileges.
If you can provide more info on your scenario I could provide a more complete answer.
I want to check and validate Json Web Tokens in headers of the incoming requests to the API gateway before passing them to microservices. But the logic for issuing tokens will be in User service behind the Gateway. Is there a way to validate incoming request web tokens?
I tried using express-gateway. It only had in memory store. Is there a way to get it from a db like MySql?
thanks a lot for the message.
Express Gateway supports in Memory store and Redis as well, so if you want to persist your users, that should be the way to go.
According to your message, it seems like your users are stored in another database, backed by Mysql. In this case, what'd be the best would be to make sure that every time our system creates an user, it should create an user in Express Gateway with a set of credentials (depending on the login flow you want to use).
Once that's done, all you need to do is configure a pipeline with the jwt or oauth2 policy to validate (and issue) the tokens.
If you need any more help, feel free to answer here or stop by our Gitter channel.
Cheers!
I have a web client that talks to a .NET webservice for data and control of various household systems. I want to expose nest thermostat control in the web client via the .NET webservice. I understand the typical auth process requires "users" to authenticate a client using the provided "works with nest" page to get a code and then use that code to get a token. In my case the .NET webservice is the client and there is no user or UI to allow a user to "accept" and thus I need a way to get the auth token (or pin) without pushing a webpage in front of a user? Is this possible? thanks
UPDATE:
I manually went through the process of generating a token and discovered the expires number to be rather large (10 years). Given that is there any reason I can't just use that token in my .NET app with all future rest calls?
The token will only allow you to access the approving account, so if this application is for your personal use, then yeah, just hard code the token.
If you .NET service can handle an oAuth callback (A little confused about how you would have a webservice that can't serve HTML) then you can enter the callback URI into your client settings on developer.nest.com and the PIN will be returned directly to the service for you. The callback URI must start with https:// or http://localhost though.
Just a note, if you're using a web service, specifically a SOAP service, then XML will be returned on the callback, not HTML. In the case of the nest API, JSON is returned.
In the case of oAuth, it's done on the lower level protocol of http using headers, URIs and the like. Here is the link to the standard:
https://www.rfc-editor.org/rfc/rfc5849
I'm building a mobile app and a ServiceStack web service back-end. The Authentication stuff in ServiceStack looks great but easy to get lost in its flexibility - guidance much appreciated. I'll be using my own db tables for storing users etc within the web service. I'd like to have a registration process and subsequent authentication something like this:
the user initially provides just an email address, my web service then emails a registration key to the user
the user enters the key. The app sends to the web service for registration: email, key & a unique device identifier.
the web service verifies the key and stores the email & device id. It responds back with an auth token that the app will use for later authentication.
Then subsequent web service requests would provide the device id and auth token (or a hash created with it). The app is not very chatty so I'm tempted to send the authentication details on each web request.
Question 1: Should I hook into ServiceStack's registration API or just add a couple of custom web service calls? e.g. without using ServiceStack's registration I would:
post to a registration web service with the email address and device id. My web service would send the registration email with a key and add a record to the user db table.
when the user enters the key it would again post to the registration web service, this time also with the key. My web service would validate the key and update the user table marking the user as registered, creating and recording the auth token & returning it to the caller
subsequent requests would be sent using http basic auth with the device id as username and the auth token as password. The service is not very chatty so creds will be sent with each request.
I'll implement a CredentialsAuthProvider that'll get the creds with httpRequest.GetBasicAuthUserAndPassword() and validate them against the db data.
But it feels like I should use registration built in to ServiceStack.
Question 2: What's wrong with passing the authentication details with each request? This would make it easier for composing my app requests but it doesn't seem 'done' based on the ServiceStack examples. Presumably that's because it's inefficient if you have lots of requests to need to re-authenticate every call - any other reasons? My app will only make a single web request at most every few minutes so it seems simpler to avoid having sessions and just re-auth each request.
Question 3: Am I on the right track subclassing CredentialsAuthProvider?
Question 4: Is there any point using the auth token to generate a hash instead of sending the auth token each time? All communication will be over https.
Answer1: It will be OK. if you give multiple call as per requirement. Normally authentication works based on cookie, now you can store it on client and/or on server and match the user with it. Again here if you are using device you, can always use device instead of user to map and authenticate user. Based on your requirement.
I will prefer to use provider as it hides many details which you need to do manually instead. You are on right track. There are many blogs specifically for authentication and how to create custom authentication with service stack. If you like let me know I have book marked some will give it you. Best way to search latest one is checkout twitter account of Servicestack.
Answer2: This is again, I say as per requirement. Now if your user will be in WIFI zone only. (Mostly true for business users), then there is not limit for calls. Just give a API call and do the authentication in background. Simple JSON token will not hurt, It is few bytes only. But again if you have big user base who is not using good internet connection then it will be better to store authentication detail on device and check against that. Just to save a network call. In any case network call is resource heavy.
Answer3: Yes you are on a right track. Still check out blog entries for more details. I don't remember the code snippet and how it works with last update so I am not putting up code here.
Answer4: This is answer is little complicated. Passing data over https and saving user from Identity fraud is little different thing. Now, if you are not generating auth token (hash based value) then you can pass user also over the http or https. Now, this can be used by another user to mock first user and send data. Even data is being passed through https but still data is getting mocked. Hashed based value is used to avoid this situation. And also there are couple of other business use cases can be covered using auth token.
Please let me know if I have understand you questions correctly and answered them?? or If any further details is required??