resource server, those two are generally separate server from your OAuth2 provider, the later responsible for serving resource checking if there a valid token the former, giving authorisation by providing the hop access token,

user (resource owner),

client (mobile app).

The most common flow is based on Authorisation code grant. See it explained in my last post with GoogleDrive as an exemple.

Delving deeper in OAuth2 specification, there is several grant types in order to provide an access token. From the spec, we can extract four authorisation grants:

Authorisation code grant

Implicit grant

Resource owner credentials grant

Client credentials grant

Authorization Code Grant

As said earlier, without doubt the most popular one and most probably the one you need ;)

On native app, this flow can be achieved either using an embedded browser or redirect the user to the native browser and then are redirected back to the app using a custom protocol (in iOS land, we use URL Schemes). For AeroGear-iOS OAuth2 library we use the latter. We’ll discuss more in details why in next blog post.

The authorisation code grant type is used to obtain both access tokens and refresh tokens. In next blog post, I shall also talk in detail about refreshing token flow;

Implicit grant

Ok this one target pure “web” app. From the spec: “In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization)”.

Client credentials grant

if your application only shows tweets from other users, you can get authorized using OAuth 2.

but if you want any users to use your app to post tweets or do anything else on a user's behalf, you should stick to OAuth 1.0a Twitter API.

Here are the 4 basic grant types. At those, you can add Refresh token grant and the extension grant (MAC token, JSON web, SAML). And of course, how much a provider is OAuth2 compliant is also source of variants...
But that will be the subject of another post ;)