First step is now complete!
You can now log in, woho!
And all we needed (sortof) is this code:
As you might notice this is not a complete app, but this is instead the function you get routed to if you point your browser to the '/login' URL of the app. (if this seems very strange take a look at this expressjs sample)
The scenario in this case is pretty easy. We have 3 things that can happen.
- Nothing extra is specified in the URL
- A 'code' is specified
- A refresh token is specified
When nothing is specified we treat the request like an initial request and pass it on to Microsofts login service.
This URL looks something like this:
The first time the user will see a login screen or a "Grant access" screen and then be redirected back to the app.
If the user has already accepted the app there will be an immediate redirect back to the app.
This redirect from Microsft will include '?code=[THE CODE]'
If the code is specified that means the user has accepted our grants and we can now request some lovely tokens from Microsoft to get the actual access tokens and what not. This request looks like this:
When doing this we will get several interesting things back:
- Access Token: This is what we'll use when we later talk to the OneDrive service
- Authentication Token: We can use this token to verify that the response is valid (aka no one is pretending to be the Microsoft login service)
- Refresh Token: This token has no expiration date, it can be used to get new tokens.
We want the Refresh Token because the access token got a expiration time. Since we don't now when we actually need to upload files to the users OneDrive we need a fresh token to be able to get a new token at that time.
This is just for debugging right now but If I specify the refresh token I will do a request that looks very much like the request when I had the code and I will get the exact response back (but with new tokens)
This will most possibly be used on the server side when we're actually doing the upload of the files because it could been an unlimited amount of time since the actual authentication.
Why not get the tokens on first request?
One of the first things I thought too myself when trying this out was that it feels like it woulf be easier to not just return a code on the first request but actually just return the needed tokens in the redirect.
But I then realized it and since it isn't that awesomely explained on the OneDrive docs I thought I might put in a small note about it here.
The tokens are 'sensitive' data that we really don't want to share with anyone. With the tokens you can do everything specified in the scopes, this could be anything from just reading the display name to sending emails, deleting files and all kinds of dangerous stuff! So we don't want that to happen.
"But the redirect already return the 'code' that can be used to get the tokens?"
That's the pretty part, it doesn't :)
The code is needed, correct. But the client secret is also needed, and that isn't included anywhere on client side or seen in a clear request.
Does this sound complicated? I had to draw a pictuer for myself to get it, here it is
(the blue lines represent what I would consider 'safe' requests, and the ref requests I would not consider as safe)
The client secret is safe and sound on the server and will only be transfered directly to Microsft to get the required tokens without touching a single client (unless you're doing everything from a client... which I'm going to say right now is a BAD idea, using a server proxy instead that deals with the secret is considered a better option)
Right now I think I should sleep (the luxury of not being at an actual hackathon)
Tomorrow I'll take a look at the main functionaly, actualy uploading files!
Doesn't seem to hard, just need to create some pretty muultipart POST request (totally new to me).
New is fun!
See you tomorrow!