I'm making an Ajax call in the UI to the API, so the localhost needs to be able to query the API. Users of the platform should be able to access the API, but need to use a token I already provide.
Is there a way to allow anonymous API usage locally only?
I looked into JWT and it does not seem to be the right fit.
As I've pointed out in the comments, JWTs should suffice in this case as, from what I've understood, you're not handling any extremely sensitive data (which can be hashed and not exposable to the user using JWTs as well) but want to validate each request. Using the same link you can check the validity of a token in their debugger.
Related
currently I plan on using AWS Cognito to handle my authentication for users. I want to do a simple registration and login.
So far, I have created a function which calls cognito's initiate_auth method. Currently my flow works like this:
User goes to /signup
After filling the form, I create a new user in the cognito backend and send them a verification mail
User is redirected to the /login page
The login function in the backend calls initiate_auth with the username and password, and retrieves some token information like this
{'AccessToken': '***', 'ExpiresIn': 3600, 'TokenType': 'Bearer', 'RefreshToken': '***', 'IdToken': '***'}
I believe these tokens are in the JWT format. My question now is, what exactly do I do with this? I know that I need to store this data, securely, somewhere, but I'm not sure what the best practice is.
I've heard that these tokens/data need to be saved in cookies in order to access them properly, but I also heard that there are some encryption problems, which is why I was looking for a library which handles this for me. I've come across this library: https://github.com/SimpleJWT/django-rest-framework-simplejwt
However, it seems like in order to use this library, I need to be using the DRF. However, my app is currently not the server handling/issuing out the tokens - it just retrieves them from Amazon. Do I need to convert these tokens for my application in some way?
Let's say I did have to use the DRF - then do I need to wrap the token handling functionality in it? I really don't know where to go from here. I am assuming that my authentication functions should be part of an API anyway, since, if I want to expand to a mobile version of the app, I can simply call the authentication function from my API. But I suspect that this would be a different step...and maybe I can kill two birds with one stone here.
Struggling to get this fully working - here is my app workflow:
React frontend - user authenticates w/ Cognito directly (using AWS Amplify) - I've got this working fine. The frontend needs to handle this, as it makes separate direct calls to other AWS services.
DRF backend - React then makes API calls to DRF endpoints using Amplify.API, which includes the x-amz-security-token in the request header (this appears to be the Session Token returned by Amplify's call to the cognito-idp service). So now the backend has the Session Token (but not the Access Token or Refresh Token)
The backend then simply needs to verify that the frontend user (whose authenticated identity I assume is represented by the Session Token) is a valid and currently authenticated user according to Cognito. So the backend needs to make a separate call to Cognito to verify this.
This is where I'm failing - I've looked at django-warrant, but I can't discern from the documentation whether this is appropriate for my use case (or even how to really use it - the default setup suggested results in various boto3 errors to do w/ lack of credentials, etc.). I've also looked at warrant and directly at boto3 and botocore but it is not clear to me where to make all this happen. Am I missing seeing some kind of is_user_valid and is_session_token_valid methods in these libraries?
If someone knows how to do this directly w/ django-warrant it would help, and if not a little advice on the best way forward would also be appreciated (do I write my own authentication backed or middleware to intercept the request, authenticate somehow w/ boto3 or botocore, or what?)
Many thanks
I'm attempting to write a simple script that I can run from my command line that will send warning messages to certain users on HipChat, and I've run into some issues around authentication. Ideally, I'd like to have the script prompt the user for their HipChat username and password, and use them to log into the Hipchat API. However, it seems that Hipchat doesn't offer this functionality, and I'm not sure what to do.
The documentation seems to suggest I manually generate a token, and use that instead. While this is definitely an option, it seems a little less user friendly, so I wanted to double check that there wasn't an alternative before going ahead. I want to avoid the installation and OAuth flows as much as possible (I don't think they're an option).
Any thoughts? I'm open to alternative suggestions, although it really seems like Basic Auth or simple token generation would be an option.
The hipchat APIs don't support username+password as authentication, for security reasons (you don't want your password flowing through every API call).
The OAuth flow you mention is used for the integrations. If you want to try the API manually (or to script them), there's a simpler auth flow:
Generate an API token by going to https://hipchat.com/account/api (make sure to select the right scopes for the APIs you want to call)
Call the API with the token as an authorization header Authorization: Bearer YOUR_TOKEN
[Much less secure] Or add your authorization token to the API URL as a query parameter: https://hipchat.com/v2/room?auth_token=YOUR_TOKEN
Full information is available here: https://developer.atlassian.com/hipchat/guide/hipchat-rest-api
I'm going to build an API in Flask for a (to be created) app which will be built using PhoneGap. In the API many calls will need authentication.
To get into the topic I was reading this tutorial on creating authentication for a Flask-built API. In this tutorial they first show how a user can use basic password authentication for every call, after which token based authentication is introduced.
As far as I understand, the client who calls the API should simply get a token and authenticate every subsequent call with that. In the meantime, the client should keep track of time and either get a new token every 9 minutes (before the old token expires) or simply keep on calling with the token until the client gets an Unauhorized Access message. Am I understanding this correctly?
Moving on, I wonder how it works with Apps on which you login on your phone and then are always logged in whenever you open the app (like for example the Facebook app). This is obviously more convenient to the user than always needing to provide the username/password and I would like to implement something like that as well. I wonder though; how is a permanent logged in feature like this implemented on the server side? Is it done by providing the password and username for every call, or using a never expiring token, or yet a different way?
All tips are welcome!
I've done what you want to do with:
Flask-security https://pythonhosted.org/Flask-Security/:
To manage users and permissions.
Flask-oauth-lib https://flask-oauthlib.readthedocs.org/en/latest/:
Provide oauth functionnality.
So, you have to take a look at Oauth flow, implements a user backend (like Flask-security) and implements an oauth server (with flask oauth lib for example) and bind it to your user backend.
After that, it's oauth standard flow. You just have to give the right token on each api calls and TADA !
With this way you can also, if you want, give access to your api to third-party app thanks to oAuth :)
Essentially the same problem as this question but looking for a solution in Python. How to work around Twitter OAuth?
Ideally, I dont want to have to go through the hoops of setting up a user/login interface and backend since the work I'm doing is for internal purposes.
I would also like to bypass the part where I need to re-direct the user to Twitter for authorization.
Thanks
You'll want to use Twitter's OOB flow. This is explained nicely in this answer
Twitter API - OOB Flow
So, reading between the lines a little, you have a twitter account and a password because this is internal, so you don't want to go with an auth process that requires a user to interact with it?
The idea behind OAuth is that you don't ever find out what the user's password is; I agree that if I'm right about what you are trying to do that it isn't the right thing. The OOB Flow suggested by JohnD has the same problem.
If you do have an account/password, then you can work with submissions to the website directly, using the login form and the tweet form. Unfortunately this means you don't have access to the API (they nuked basic authentication via the API last year) -- depending on what you're trying to do that may or may not be a problem.
Edit:
Use OAuth and remember the token. It never expires, according to the twitter API docs, and since you presumably have some limited number of accounts that you care about, you can just jump through the OAuth hoops once for each account and you're done until you need another account. You can even do the whole thing programmatically given the username and password, assuming they don't stick a captcha in there at some point. But I suspect your best bet is to just use OAuth and store the tokens.
I just found this bash script that works, tested personally, just change --ssl to --sslv3.
It's based on a simpler auth method used on mobile.twitter.com, you can use the same principle to deal with it using urllib2 and re modules.
Otherwise you can consider to lean against a site like http://www.supertweet.net/
SuperTweet.net provides a safe
mechanism to use Basic Authentication
with the Twitter API in your scripts
and other Twitter apps. Simply Sign-up
via Twitter to authorize the MyAuth
API Proxy SuperTweet.net Application
and then assign a password of your
choosing (not your real Twitter
password) that your applications can
use with the http://api.supertweet.net
API.
edit: I see now this site was cited in an article linked in an answer of How to work around Twitter OAuth?, if you already read about it ignore this part.
If you're using a desktop or mobile application, then you can use xAuth. From the user perspective it's the same as basic auth for getting the original OAuth credentials, and there's no going to external pages. Note you have to be approved by the Twitter API team to get xAuth access.
You might consider looking at Mechanize. It automates browser activity.
So you could give your username/password to your script. Then the script should pass on those credentials to http://twitter.com/#!/login.
conventionally, if you manually login from that webpage, the response will be another page based on whether the credentials you used were correct.
Same thing here: Based on whether the credentials are correct, the response is another page.
You can then check whether the response is a "login failed" page or a "login passed" page, and do what you need to do from there.
Hope this helps