Now that we have an access token on hand, we need to save it to some place so

that we can retrieve it and use it every time we need to make a request.

There are two main places we can quickly save things to an iOS, but

which of those two we use depends on what we're trying to save.

The first place you might have read about is user defaults.

Every app has a default system that allows the application to store things like

preferences that allow app customization.

Any preferences that the user selects in settings, things like temperature units or

the text color in the app, are all saved as key-value pairs in a default database.

To get access to this database, we use the user default type,

or NS user defaults as the objective C class is called.

But over here, user defaults is not what we need.

We need to save our data securely,

because we really don't want access tokens being compromised.

Why go through all the trouble to make fetching the tokens secure,

if we're just going to drop the ball on our end when we store it?

To securely store data we're going to use the keychain API.

Keychain services is Apple's solution to security problems, particularly

those where users store passwords or other private information in plain sight.

The keychain does some really important stuff, so

rather than summarizing, I'm going to read a snippet from the docs.

The keychain secures data by encrypting it before storing it in the file system,

relieving you of the need to implement complicated encryption algorithms.

The system also carefully controls access to stored items.

The entire keychain can be locked, meaning no one can decrypt its protected

contents untill it is unlocked with a master password.

Even with an unlocked keychain, the system's key chain access policy ensures

that only authorized apps gain access to a given item in the keychain.

In the simplest case,

the app that created an item is the only one that can access it later.

However, if we need it,

keychain services also provides ways to share secrets among apps.

Now, there's only one minor problem.

The keychain API is kind of a pain to use.

So if we go to Help > Documentation and API Reference, and then start

searching for a keychain, you should get an iOS Keychain Services Tasks result.

Let's click here.

So this document describes how we add an item to a keychain,

find an item in a keychain, and so on.

If we scroll down a bit and click on the line that says SecItemAdd,

this is how we add an item to the keychain.

You'll see here on this page, that this is a global function, so right there,

and this is not a method on a type.

Now if you inspect the parameters a bit closely,

you'll see types like UnsafeMutablePointer and

then it's a generic type, CFTypeRef, that is optional, and then this is optional.

Basically, this is all old C code that is bridged over to Swift without

any sort of wrapper.

C code is unsafe as S, S being the word I can't say on here,

because some of you watching this might be a little too young.

So, what we're going to do is use another third party library that provides a much

better experience by creating Swift types around all the C code.

Before we do that though, a quick overview on how we use the Keychain API.

The Keychain is the actual encrypted storage our

app is going to use to store the data.

iOS controls this keychain, so

we don't have to worry about the actual security implementation.

We just need to correctly insert the data.

A keychain holds any number of keychain items.

A keychain item is a piece of sensitive data you want to store in the keychain.

Keychain items belong to an item class.

The item class determines what kind of information

we store in the keychain item by defining a set of attributes.

Okay, so what types of classes are we working with?

There's a generic password class that includes a service and

account name attributes, and then there's an Internet password item class,

which includes attributes for things such as the server, the security domain,

the protocol type, path, and so on.

Some attributes such as the creation date and

a label are common to all item classes.

Others are specific to the class.

For a keychain item that needs protection, such as a password, or

a private key, the data's encrypted and protected by the keychain.

For keychain items that do not need protection such as certificates,

the data isn't protected, or encrypted rather.

Encrypted data is inaccessible when the keychain is locked.

So in iOS the keychain is automatically unlocked when your device is unlocked.

So your application always has access to its own keychain item data while the user

is present, basically while the phone is unlocked.

Okay, so we're going to save our access token as a generic password item.

We're going to go back to Google to github.com, okay, so

we're going to go to github.com and

then in the search bar we're going to search for a swift locksmith.

This is the library we're going to using.

Now I made sure that this library passes all my sanity checks, but

I'd like you to go ahead and do the same.

So we're going to add this to our cart file, and run the script again.

So we're gonna go back to the terminal window, make sure we're in the correct

directory, and then we're going to open the cart file again, in Xcode,

by running the following command,.

So, open Cartfile ar a quick tip is if you're in terminal,

you can just keep hitting the up arrow and

it'll go through the commands you've typed before, and hit Enter.

Okay, in the read me for the repo, which we should find on the site.

By the way, if you're wondering what I mean when I keep saying repo,

that's a way github, this website, organizes a project.

So all of this is called a repository.

Anyway, if you look at the documentation, you'll see under installation there's

a Carthage section, and it includes what you need to include, or it specifies,

what you need to include in your cartfile.

Now pay close attention to the fact that there's no version number

specified over here.

So, if you pasted this line here into your cartfile as is,

then anytime you ran Carthage update you would get the very latest version.

So, right now, that's not a problem, but remember if there was a major change to

Swift that was incompatible with the current version, let's pretend Swift 4 is

going to be that way, and this library was migrated to swift 4,

but we hardly migrated our project over yet, at that point Carthage

would fetch the wrong library and you would have to figure out how to fix it.

Which it usually means you would have to post something on the forum and

wait till someone helps you, and that gonna take too long.

Since there's no version number mentioned here, what do we do?

Well at the top of the page, over here,

you should see the section labeled Releases.

Whenever a library author tags and

releases a new version it is listed on this page.

Now the official release is pointing at version 2.0.8 despite there

being a 3.0.0 above that, and if you dig through the code history for

this release, you'll see that 2.0.8 contains Swift 3 code.

Now one way you can do this is by clicking on this link right here,

which goes to the actual history, and then you can read through here, which I did,

and you'll find out that this contains Swift 3 code.

But we're not going to that, so we're gonna go back, and

then back to the main page.

Now on the read me,

right above that Carthage snippet, right over here under installation,

it actually says that Locksmith 3.0 and greater is Swift compatible.

So what we're going to do is add version specifier to our cartfile saying anything

above three is good, but up to the end of three basically,

not including version four.

So I'm going to copy this, Cmd+C to grab that.

We'll go back to my cartfile, hit paste, and

then we'll include the tilde and an open angle bracket,

or rather, that's a closing angle bracket, and then 3.0 as the version.

Okay, so hit save, go back to terminal, and again we're going to run.

Keep clicking the up arrow until you get carthage update platform iOS no

use binaries, and hit Enter.

That should finish fairly quickly, and once that's done, you're going to

type out, let me bring this up here so you can see it, that didn't help.

Okay, you're going to type out open.

with a space in between the two,

to open the current directory in the finder window.

Again, we're going to navigate into Carthage > Build > iOS,

and then this time, we're going to grab the Locksmith.framework and we're gonna

put that in the same spot as we did earlier, so in the general section of

the project settings, at the bottom where it says Linked Frameworks and Libraries.

We'll drop that in there.

Remember, we also need to edit our build phase script.

So we added this run script here.

The only thing we need to do now is,

we need to specify this new framework as an input file.

So we'll click + again, and it's the same thing as before,

so we'll say Carthage/Build/iOS/Locksmith.framework.

Okay, and then hit Cmd+B to build, and

make sure everything is more or less okay, cool.

So now that we have that locksmith framework in there,

I'm going to go back to the YelpAccount file, and

we're going to add a few methods in here to save and load our data.

So we'll do this in an extension of YelpAccount.

Now, the first method I want to add is a save method.

We'll make the save method a throwing one so

that if there are any issues saving the token,

we can deal with it in the permissions controller where we call this method.

So say fun save( ) throws.

In the body of the method we are going to use the locksmith

framework to do the actual saving.

Now there are two ways of using locksmith, and it's quite flexible, and

powerful powerful in its design.

If you go back to docs, and head down to quick start,

the first way to do it is to call the relevant save and

load methods directly and pass at some data.

The second way is to use the power of swift protocols.

So we use a protocol based approach, and

we would add protocol conformance to the YelpAccount struct.

So as you can see here they have a TwitterAccount struct, and

they've added conformance to specific protocols, CreateableSecureStorable,

GenericPasswordSecureStorable, and so on.

When you do that you have to specify a few properties, but in return you get save and

load methods for free.

So since this handles some of the magic for

you we're going to go with the first approach.

We'll start by importing, up at the top, the Locksmith framework.

So now inside the save method, we're going to call locksmith save data method.

The token information is going to be saved in a dictionary, which needs keys, so

let's create some static constants right here in the extension, to serve as keys.

So this is a struct Keys, and in here we'll say,

static let token = "token", and this, again, is just so

that we don't make any typos when typing these keys out everywhere.

We'll say, static let expirationPeriod = "expirationPeriod" and

static let grantDate = "grantDate".

Okay, so inside save, we're going to call locksmith save data method which is

a throwing one so we'll need to use the keyword try, and

since we're just throwing this error on we don't need a do catch statement,

or a try question mark, or anything like that.

So we'll say try Locksmith.saveData and

we're gonna use this first one that takes some data for a user account.

Okay, so let's define a dictionary now.

Here we're going to simply assign a set of keys for

the values contained in the instance.

So empty dictionary first, and

then first one is Keys.token: and then the value is accessToken.

We'll do Keys.expirationPeriod: and then the value is the expiration value,

and then finally we'll say Keys.grantDate and

the value is the grantDate, but we're gonna store it as a time interval.

So, we'll say timeIntervalSince1970.

The second parameter here asks for a user account associated with this data, and

typically this is where we specify a username for example.

Since our access token is from two machines talking to another,

we'll just specify the service instead, so we'll say YelpAccount.service, and

of course this is going to create an error.

So back in the type we'll say, static let service = "Yelp".

To load the data we're going to do the opposite.

We're going to fetch the dictionary, unpack the data, and

create an instance of the type.

We'll make this method a static method since we won't have an instance

at that point, to call it on, since we won't have any of the data.

So we'll say static func loadFromKeychain( ) and

this method will turn an optional value of YelpAccount making it easy for

us to determine whether we got a valid value back.

So inside the body we'll start by fetching the dictionary.

Say guard let dictionary =

Locksmith.loadDataForUserAccount (user

account is YelpAccount.service).

From here we'll just get the relevant values using the keys we created.

So, let token =, or we'll do this all in one guard statement.

So, let token = dictionary[Keys.token] and

we want the value to be a String.

For the expiration the key here, so we're gonna get this out of the dictionary,

the [Keys.expirationPeriod] and

this is going to be a TimeInterval value, so we're going to try and pass that.

Finally, we wanna say let grantDateValue

= dictionary[Keys.grantDate].

Remember we saved this as a time interval, so we're gonna cast it to that as well.

If this doesn't work, if we don't get any of these values back,

we're going to return nil.

So after we construct a date, for the grantDate, which we can do pretty easily.

We'll say, let grantDate = Date(timeIntervalSince1970:

grantDateValue).

Now we can return an instance of YelpAccount.

So we'll say return YelpAccount and we'll just use it's standard initializer.

So token, expiration, and grantDate.

Okay, this is quite a bit of code, but now back in the permissions controller we can

use these methods to finish up the implementation for authorization.

So if you navigate to PermissionsController,

inside the requestOAuthToken method,

we've now created a YelpAccount using the data we got back.

Let's pick up right where we left off.

So since this saving method, at this point we wanna save it, and

since this saving method is throwing, we need to wrap that in a do clause.

Inside we'll say, try?

account.save( ).

If this works, we're going to set the oauthTokenButton's text,

so setTitle("OAuth Token Granted", for: UIControlState.disabled),

and then we're gonna disable the button, so

self.oauthTokenButton.isEnabled = false.

Note, that I'm using try with a question mark here to let it silently fail just so

I can avoid error handling.

You really shouldn't do that, and instead you should get some practice with

cleaning up all your code and doing valid error handling.

Okay, if the save worked, we're gonna change the title of the button and

disable it.

So let's test this out.

We're gonna hit run.

Okay, so our permissions controller popped up, and in here,

we're going to hit the Request OAuth Token button.

If this works, in a second you should get a grayed out button

with a message that the OAuth token button was granted.

Perfect.

Now we have a way to communicate with the Yelp server.

In the next video, we're going to start tackling location permissions.

Before we get there, I want you to take a small break and work on some UI for me.

Right now when we hit this Request OAuth Token button,

there's really no indication that there's a request in progress.

I want you to show the user something,

preferably an activity indicator to show that work is happening.

Also, we haven't really accounted for

the failure case, so go ahead and try to fix that up too.

An easy way to test what happens is to go up to the top of the permissions

controller and omit a single character from your client's secret and

then run this flow.

The authorized method will call back with an error and

all we're doing now is logging, so you should try and clean that up for the user.

When you're done I'll see you in the next video.