I am building a non-interactive application that works with the Valence API, and I am having a hard time wrapping my head around how the authentication (specifically, the process of obtaining the User Id and Key) is supposed to work. My D2L administrator has provided me with my App Id and Key and I have been able to use them and the getting started sample to obtain my User Id and Key, but I cannot figure out if it is possible to get the latter in a purely non-interactive fashion.
I would like to know if this is possible at all, or if the interactive process of obtaining the API credentials is required.
Currently, the interactive process is required in order to obtain a User ID/Key. It should be possible to fake this by simulating the posting of the login form, if you are really desperate, but obviously this is an unsupported arrangement and would be very fragile and prone to breakage if anything changed in the login form.
Related
I am writing an SPA using Vue.js, authenticating the user from Azure Active Directory (AAD) using OAuth and OpenID. I have searched for a long time for the best way to do this, and have consistently been referred to a library called msal.js. This is working, in a way, as I am able to get the token id successfully. But, immediately after getting the token id, the page always automatically redirects back to the authorization URL. This infinite loop has been reported as a bug here. I have tried the workarounds recommended on that bug report page, but they are not working for me.
So, my question is, does anyone have any advice as to what I can try next? One person in that bug report thread said they are writing their own plugin instead of using msal.js, but that seems like a big undertaking. I have a hard time imagining there is not a better solution out there.
I have an app, client side, that uses auth0 for accessing the different API's on the server. But now I want to add another app, a single page app, I'm going to use VueJs, and this app would be open "ideally" w/o a user having to sign in, it's like a demo with reduced functionality, I just want to check that the user is not a robot basically, so I don't expose my API in those cases.
My ideas so far:
- Somehow use recaptcha and auth0 altogether.
- Then have a new server that would validate that the calls are made only to allowed endpoints (this is not of my interest in the question), so that even if somehow the auth is vulnerated it doesn't leave the real server open to all type of calls.
- Pass the call to the server along with the bearer token, just as if I was doing it with my other old client app.
Is this viable? Now I'm forcing the user to validate, this is more a thing about UX (User-experience), but I'd like a way to avoid that. I'm aware that just with auth0 I can't do this see this post from Auth0, so I was expecting a mix between what I mentioned.
EDIT:
I'm sticking to validating in both cases, but I'm still interested to get opinions over this as future references.
At the end, with the very concept of how auth0 works that idea is not possible, so my approach was the following:
Give a temporary authenticated (auth 0) visitor a token which has restricted access level, then pass the request to a new middle server, the idea is to encrypt the real ids so the frontend thinks it's requesting project A123456etc, when indeed it's going to get decrypted in the middle server to project 456y-etc and given a whitelist it will decide to pass the request along with the token to the final server, the final server has measures to reduce xss and Ddos threats.
Anyway, if there's a better resolve to it I will change the accepted answer.
You could do a mix of using recaptcha for the open public, then on the server side analyse the incoming user request (you can already try to get a human made digital fingerprint just to differentiate with a robot-generated one) and the server (more a middle server) makes the call to you API (and this server has limited surface access)
What we normally do in these situations (if I got your issue correctly) is to create two different endpoints, one working with the token and another one receiving the Recaptcha token and validating it with Google servers.
Both endpoints end up calling the same code but this way you can add extra functionality in a layer in the 'public' endpoint to ensure that you are asking only for public features (if that cannot be granted just modifying the interface).
I have two questions about Box's Oauth2 API in a testing environment.
Is it possible to have multiple redirect_URI addresses? I'd like to use one address for production (e.g., https://my_site.com/box_redirects_here), one for ongoing development (http://localhost:8000/box_redirects_here) and one for automatic UI tests (http://localhost:8001/box_redirects_here). As far as I could see, the only way to do that would be to create three different Box applications - is there an easier way? BTW, both Dropbox and Google Drive do support multiple redirect URIs.
I have a set of automatic tests that I'd like to run a few times a day. The challenge I'm facing is that every time I run these tests, my refresh_token is invalidated, and I can't use it again - which means I can't run the same set of tests a few hours later without manually getting a new token. One solution would be to save the refresh token, for example in a file, so I could reuse it across testing sessions. But:
It's really cumbersome.
if different developers are running these tests from different machines with no common file system that doesn't really work.
Again, for whatever reason this doesn't seem to be an issue with Google Drive or with Dropbox.
This is not currently possible, and I agree that would be nice.
Your best option is to save the access/refresh token pair to a file or a database (in the event that there's no common filesystem.) The OAuth2 spec grants implementers wide latitude on how they issue refresh tokens, if they issue them at all (I don't think Dropbox does.) While Box's implementation makes integration testing a bit challenging, I think that it ultimately hews most closely to the spec's recommendations.
For your first question, you might be able to get close to what you want by using the redirect_uri query parameter. Although you won't be able to supply an arbitrary redirect URI, you can give one that has the same base URL as the redirect URI in your app console.
From the OAuth tutorial:
Wildcard redirect_uri values are also accepted in the request as long as the base url matches the URI registered in the application console. A registered redirect_uri of https://www.myboxapp.com can be dynamically redirected to https://www.myboxapp.com/user1234 if passed into the request redirect_uri parameter.
For your second question, John is right - Box invalidates a refresh token after it has been used. Although this can be annoying, it's also more secure.
I'm starting to work with Box a bit... https://developers.box.com/docs/#oauth-2
I'm thinking I'm going to use Box for image (and file) hosting. I've used S3 for this task in the past, but my cohorts seem to want to use Box for some reason. So in order to use their API, you authenticate with oauth2... which involves a redirect uri... then you get a token, and you're in, right? I know how to use this to let people log in to your site, and whatnot, but I'm not sure I get how I could use it for the task at hand.
I don't want to have to log into box manually (or have any users, obviously), and I don't want to attach anything to a session to capture the auth token (one of the ways I was thinking of doing it). Is there a way to authenticate silently, with your client_id, secret, options, and authorization credentials?
Maybe I'm confused... if anyone would like to shed some knowledge on me, that'd be amazing.
This is a Rails app... tinkering with the ruby-box gem (but that's not super relevant)
If your application is trying to manipulate a user's data, authorization from the user to your client application is definitely needed. So, you cannot do the authentication/authorization silently.
On the other hand, if your application has no intention to touch any user data and just calls Box APIs which are not associated with any user, it is possible IF Box supports "Client Credentials Flow". Check Box API document to see whether it supports the flow or not.
I'm think something like Facebook apps here. User generated pieces of code that people can write to interact with my app.
I understand how an authenticated API works, but this seems a little more complicated because not only does the APP have to authenticate itself (with a regular api-key) but the USER using the app has to be authenticated somehow too, without giving the app free reign.
I've been reading a bit here to see how FB does it: http://wiki.developers.facebook.com/index.php/How_Facebook_Authenticates_Your_Application
And it looks like you have to pass a signature in addition to the api-key along with every call, but I'm having trouble wrapping my head around how this gets generated and used on the other end (my server).
Figure there must be a simple explanation of this out there? Thanks!
P.S. I'm building a Rails app if there are any applicable gems/plugins.
This may be what I need:
http://github.com/phurni/authlogic_api
Did you have any success with authlogic_api? I'm working on the server-side for a Steam game, where users are logged in through Steam, so I'm only responding to REST calls from the client (no user login required). The rdocs for authlogic_api give some brief set-up info, but I'm struggling with what to do in the application_controller to restrict access; essentially the equivalent of this code from the authlogic example:
http://github.com/binarylogic/authlogic_example/blob/5819a13477797d758cb6871f475ed1c54bf8a3a7/app/controllers/application_controller.rb