I'm dabbling with the MusicKit API and came across this in the sample app.
Keep in mind, you should not hardcode the value of the developer token in your application. This is so that if you need to generate a new developer token you are able to without having to submit a new version of your application to the App Store.
This makes me wonder where I should store the token since it has a maximum expiry of 6 months. Is the idea that I would regenerate the token on the server and have the app periodically request a new one? Am I missing something obvious?
I don't know MusicKit but I imagine you store the token in the keychain after requesting it from a server that you control. That way the app will work without an internet connection (after the first fetch of the token). Your app can ping your server when there's a connection and ask if there's a new token.
The other option is just to store it in the app's Documents directory if it doesn't need to be secure. The main difference is that they keychain data will survive a re-install. In either case it has to come from somewhere outside the app bundle (like your server).
Related
As you know many apps use keychain to save user login name and password, but is it really safe? especially on device jail break mode. So another solution is to use Outh2 protocol to save those confidential infomation on server side which needs many changes on both client and server side (for my app).
How do you guys handle this tough issue? Anyone who knows please share and thanks in advance.
Keychain:
It has two level encryption options
lock screen passcode as the encryption key
key generated by and stored on the device)
But when the device is jailbroken its not safe too.
oAuth:
Eventhough you store credentials in server you'll have to save the OAuth TOKEN in client side there is no place better than keychain to store it in client side.So now comes possibility of extracting the TOKEN on jailbroken device.
As far as I know in most apps they use one of these approaches.
If you need those data to be very very secure.
Suggestions:
Store OAuth token in server not in client
Store the Encrypted Credentials in Keychain and store the encryption key in server.This approach would be easy for you since you said adopting OAuth is hard for you.
Note:
There are some open source libraries available which detects if the device you run or app is cracked if so you can take action like deactivating TOKEN,deleting critical resources,locking app etc.
I'm working on an iPhone app that is logging into a webservice and it's been asked of me to get the account login management into the settings page (i.e. next to Twitter, Facebook and Vimeo). From what I've been reading about the accounts framework, it appears that only those few companies have that ability.
I currently have it set up and working asking for login info periodically and polling the webservice for validation, but we're trying to move toward supporting moderately offline use, which means we need to have some sort of account info managed on the phone itself.
Can I use the built-in account framework for our own login credentials or is that not something that's available to a regular dev and I'll have to look for another way to do it on my own? Is that something that the keychain would be better for?
Using the keychain to securely store the users credentials is a good idea to start.
If I am understanding your question about a "built-in account framework", I don't believe there is a local framework for account management on the device itself that I am aware of that would be useful in this circumstance.
I've had to build an app that needed to authenticate to a web service that also needed to have some offline access. I ended up recording the validated authentication date and time in the NSUserDefaults and would let the user use the app for a 48 hours period before they had to re-authenticate. Their data was queued locally and when they had online access again, I would re-authenticate and then sync the data. Not the most elegant solution but it fit the project.
I used AFNetworking (http://afnetworking.com) to track the changes in network access and used to blocks to respond to the changes.
I am locking my Mac screen with my Mac app. As I enters password it needs to unlock. The password should be generated internally. So I preffered to implement it by using "Two way factor authentication". By this my iPhone app generates a token frequently as I enters the token in Mac application it has to unlock.
I found few APIs like Gauthify and Authy. But they are generating tokens on their own apps(ie.,to get token from authy we need to install authy app in our mobile).
My requirement is without installing those apps,my app need to generate the token and communicate with my Mac.
Please guide me if any one had done it. Good suggestions are appreciable.
All these apps, including Google or any other apis use two step authentication. Here they generate a token with some private key and pass that to end user via sms or mail or any other medium. This sms or mail is registered with user in application database.
There is no need to use such app if you have your same app in your MAC and your ios Device.
You just need to identify how will you pass that key.
If MAC is generating token, and you know which device is trying to connect with MAC, you can send that token in background to that ios Device and match that. If you are using socket connections, this is option for you
When user enters Token, you can make a request to server to check that token. For this you need to send token genereated on MAC to server and save it somewhere. These tokens generally expires after some time, so run cron job to delete such tokens.
The apps you described use 2nd way to authenticate.
Hope this much help you. All depends your requirements and your approach :)
Cheers
I have to call payment gateway API from iOS code. Problem is it needs merchant credentials and I feel insecure embedding the merchant credentials in code. If someone somehow reverse engineer the code and get the credentials then the client is dead. Any advice?
I found this post Does Apple modify iOS application executables on apps submitted to the App Store? which says that app binaries are encrypted by Apple be default. Does it mean I can safely embed the credentials in code?
NO! Instead of adding the credentials to iOS app you should think about setting up a server which handles the interaction with the API, you are talking about, and let the app only interact with your server. So you can store the API key on your server and can limit whats possible by the user on server side (which will be much harder to abuse).
I am currently developing an app that's going to show a Facebook page's events in one tab. Now I'm struggling with facebook's graph API and I think I just need some more explanation about how the whole thing is meant to be.
I registered an app and got my app id, app secret and an access token. Generally it works by using my app id and the access token. But from what I've read there are two drawbacks with that.
The token expires.
There seems to be only one token at a time.
If the token expires I need to re-authenticate my app whenever the session is not valid any more. But - what's the correct way to do that? Is it by sending the request method by adding my data to the params dictionary?
And if there can only be one app access token at a time, will it result in conflicts when multiple clients are going to connect?
I want my app to just read public data, so authenticating a user is a no-go, as its simply not needed (I hope). But the more I think about it the more I think that using an app's token is not the correct way either.
How is this generally achieved? Do I need a wrapper web app to implement reading public event data?
Thanks for your help
Arne
I've never had a problem using one app token with multiple users.
As for expiring tokens, you can request a generic token, which should be sufficient for retrieving public data, by sending a GET request to:
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET&grant_type=client_credentials