Trying to understand the OAuth2 flow

Question

So, I'm implementing a Provider with OAuth2.

I get the part where the client applies for a client_id and a client_secret. This uniquely identifies them to the provider.

So, now that they have that, and they are going over SSL, why is an authorize token needed? And then, after that, why is an authorize code needed?

Also, why a refresh token?

Why can't we just go with the client_id and client_secret? I do get that for resources protected based on the end user's authorization, there is needed an extra authorization. That much makes sense. but why an auth token AND code?

Finally, is all of this needed for resources that are not end-user protected?

So, I guess that's 5 different questions to help me understand:

1. Why an auth token?
2. Why an auth code?
3. Why a refresh token?
4. Why not just use client credentials for non-protected resources (or can we)?
5. Why both an auth token and code? (I guess this may be answered by both 1 and 2).

Answer 1

Sorry for necroposting, I hope this will be useful to someone for future reference.

First they are called Authorization Code and Access Token.

1. Access Token is a string representing the right to access a resource
2. Authorization Code represents the authorization that the Resource Owner gives to the Client. In most of cases the Resource Owner is the final user who owns some resources on a server. The Client whants to access those resources, so he needs the authorization from the user.
3. Refresh Token is used to renew expired Access Tokens. Usualli an Access Token has a life-time of some minutes, while a Refresh expires after months/years/whatever. You use the access ones; when they become old you use the Refresh Token to get new Access Tokens. Note that in OAuth1 there was only one type of token that lasted also for months. Short lived tokens has been introduced to improve the protocol security.
4. I think i didn't undertand. If resources are not protected, just don't use OAuth! Anyway there is the Client Credential Grant to use when you think that the Client is the Resource Owner (here an example.
5. See 1. and 2. They are different and also they can be send through two different channels (but I still haven't found the use of different channels).

In short when the Client has the Authorization Code he says to the Authorization Server (AS): "ehi, Resource Owner said that I can access the resources!" and AS gives the Client an Access Token. Now that he has the token, Client goes to the Resource Server: "Authorization Server said that I can access the resources, look my token" and he gets the resource.

Note that there are 4 flows, every one uses a different type of Authorization Grant and only one of those is the Authorization Code. It's all asbout words. About the mechanism, first read this (a little obsolete) introduction and than read again the RFC 6749, keep these things in mind.

Hope that you now have a clearer idea.