I am making the following request in my code and mirroring it in Paw:
https://paw.pt/daoS3vF5
Paw does all the heavy lifting in OAuth 2 (which is awesome) but in my code the library I am using is not dealing with the authentication renewal requests correctly.
When I run the request in Paw I can see it renewing the auth token.
Is there a way to see the renewal message(s) going back and forth so I know what to expect in a successful transaction?
Related
I'm new to iOS and RESTful API development. I've developed a local API in Node.js that handles basic requests to and from a local MongoDB instance, and am working on user authentication via Sign in With Apple based on this tutorial from Better Programming.
It's my understanding that Json Web Tokens are one of several ways the server can verify the client, in which case user-specific information is sent back in a response. My question is this: because JWTs have a short lifespan, what is sent by an iOS device to query the database for user-specific info? Do I need to have a verification method that checks to see if the JWT is expired, and if it is, issue a new one? Or is there another token that I should be using in its place that lasts longer?
The answer to a similar Auth0 question implies that I should be creating a token server-side, and then providing it to the user. If this is the case, would this then be sent back and forth between the client and the server?
You can use the user ID provided by Apple. This is a unique identifier that is returned in the authorization credential.
I am confused if I should choose between devise-token-auth (issues new tokens for each request) or knock (issues a json web token once and keeps using it till it expires or user signs in again)
Timing Attacks: While one might say token authentication is vulnerable to timing attacks, their docs say they are securely comparing the tokens mitigating timing attacks as mentioned in this gist. Is it still flawed?
Network Failures: Is there an advantage in issuing tokens for every request? And what happens if network failures like the one mentioned in here happen?
Stealing Tokens: If something like knock-JWT is used, what happens when someone somehow (by intercepting in HTTP or even with HTTPS enabled using client side apps/extenstions to capture outgoing request headers) steals the token? Can they use it and get responses as given originally to that user?
Does the same happen when someone somehow steals a token issued by devise-token-auth? (It doesn't make it harder because they can't keep using the token again: making a request using a stolen token help get new tokens, hence can infinitely be in contact with server, however, both of them canNOT be in contact, only one can while the token held by other is unusable - is this an advantage or disadvantage?)
Is continuously issuing tokens possible in case of JWT and is it worth doing it? (Like making the server issue a new token with a new expiry after each request)
PS: I just came across these two libs for Rails for effectively managing tokens integrating with devise. If there's a better one - which typically one would use for ecommerce like APIs - I'm open to using that.
OK. So i need some guidance as I am a total iOS authentication noob.
I have a simple app. Users can login to the app, and send messages to friends. There is a web server and a MySql Database that holds the users and login information.
Question: How do I authenticate a user when he logs in safely and securely?
I have spent the last several hours hurting my brain on the following authentication stuff i found from google:
OAuth 1.0 - is said to be good. But it is a protocol and not a library. Do i have to implement this from scratch? Is this even needed in my case for authentication?
OAuth 2.0 - it seems that some sites are using this. I have the same questions for this as version 1.0. I also saw this this message from the library's lead creator literally saying f*** version 2.0 because it was bad for security. But yet so many still use it. Is it dangerous?
The creator of 2.0 has now gone on to make a completely other library because of how bad 2.0 was and because of how unscalable 1.0 was. His library is called OZ. Should I be using this for my server?
I see AlamoFire/ AFNetworking have basic authentication shown in their documentation. Should i just screw the oAuth stuff and just use theirs?
Being new to the authentication thing, all this is very confusing to me. Can anyone knowledgeable in this provide some guidance?
I am currently in the process of creating a cross-platform application and have spent quite some time researching this!
My approach to the project is using a ASP.NET Web API using OWIN middleware.
This uses bearer tokens to authenticate the user.
Using Microsoft.Identity you can limit endpoints down to roles or even individual users (Autherization)
Currently I create a user on the REST API, They log-in at the /token endpoint and then receive a token. This token is then saved to the Apple key chain and can be used to authenticate the user for further requests to the API.
As long as you use SSL this is a secure method and is used widely in many applications.
This approach uses OAuth2 also, so you'll be albe to easily integrate Facebook/Google/etc integration.
Here is a link to the Microsoft Documentation for some further reading on how I did it:
http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
Currently this is working perfectly for me for an angular front-end but would work exactly the same in iOS except you may want to save the token to the KeyChain Storage.
We mostly use OAuth 2 creating custom system on iOS to handle the authentication.
Nothing is ever bullet-proof but the 2 token system decreases the chance for stealing credential quite nicely.
The AlamoFire, AFNetworking or any other libraries you amy find have nothing to do with this though. What type of credentials you use depends on your choice or rather the choice of the API. You may use these tools to ease your communication with the API though.
So what the idea behind this is you will try to send your user name and password only once when logging in and then you will receive the two tokens which are further used to communicate. This will decrease a chance for someone to intercept the request with the user name and password which are the ultimate key to get the access to the user data.
Next is "refresh token" which is used to receive a new "access token". This call should be made every few hours or so (controlled by the API). If someone was to steal this token he would be able to use it to get further access for an infinite duration or until the owner chooses to invalidate the refresh tokens (this is what happens when you click "log out from all devices"). So this is still quite bad if someone gets it.
Then there is the "access token" which is used for each and every further request to the server. These tokens have a limited time till they are invalidated so if someone was to intercept it somehow he would have the access to the data for the duration of the token.
So assuming this is the procedure that is done on the backend this is what you need to do:
If you have the access token and is valid simply use the service
If you receive the error that the access token is invalid you need to refresh the access token using your refresh token
If refresh token reports an error you need to navigate back to the login screen
If the app has no refresh token then simply go to the login screen
There are some other things that are nice to cover such as if the request reports an invalid token you should pend the request, refresh the token and then repeat the call to the pending request. A system around this may be quite large.
This is pretty much it about the tokens and authentication but there are other parts of the communication which increase the security such as using a https secure connection. When talking about security you must take a look into every part of the communication.
I have an iOS application which connects to different APIs such as the Instagram, Facebook and Twitter API's.
I thing you need to do when authenticating via OAuth 2.0 is to get a access_token, which I have.
I just have one question, when do I renew it? I have read online that it will last a long time but still needs renewing..... Well.... how long is the time period for renewing?
Or do I renew it on every API call I make, for example when I want to GET the JSON feed of a Instagram or Twitter user, do I need to review the access_token first?
And how about when I want to do a POST to a service such as Twitter. Do I need to renew the access_token before I can do a POST??
Thanks for your time, Dan.
Renewing your Oauth token on every API request is time-expensive and too many frequent token requests could result in your application's token becoming revoked. Reference
Instead of trying to avoid sending a request with an invalid token, you should consider implementing a callback or interceptor which would check if the response contains an error code and then appropriately handle the error (display an error message or automatically redirect to request for authentication). The callback/interceptor pattern allows this error checking to be triggered automatically when each request has completed.
I'm trying to build the foundation for my iPhone app and server. I have users who will sign up and sign in from the iPhone app. In a normal website login, the http server will provide cookies to allow the user's subsequent requests to remain authenticated. How should I handle this on the iPhone? Should I just send the user/password every single time I have a NSURLConnection GET or POST? That seems excessive. Or do I use the ASIHTTPRequest framework to use cookies. Can anyone point me in the right direction for a proper implementation?
Thanks!
Sending username and password in every request is not great.
You can use anything you want to send cookies. It's just another HTTP header. But that begs the question of what is in the cookie. It depends on what your client/server architecture is. Web apps use session keys because traditionally web clients haven't held any state so the app server had to. Native clients can have all sorts of state and so generally don't need the server to provide that.
But you need authentication. That's what things like OAuth and OAuth 2 are for. They allow you to authenticate once and then use tokens that can be invalidated server-side. Kind of like very long lived sessions without data.
They are a bit complicated but there are open source libraries for both the server and client pieces or you can roll your own. Most of the complication is on getting the original token which you can short-circuit if you own the client and server. OAuth can get pretty complicated because all requests are signed with a secret token. OAuth 2 can be as simple as a shared secret (thus requiring SSL) in a cookie.