Actually, I believe much of the confusion is cleared up. Apparently I misunderstood what a Realm does. Oops!<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>The application in the original mail, which I will continue to talk about in this one, is a token endpoint. I&#39;ve been told an explanation of what that is is in order. To start out: it is NOT the thing that actually serves protected resources, that&#39;s a resource server, which is a different beast entirely. The job of a token endpoint is to turn certain kinds of credentials into an access token; the access token, in turn, can be used to access protected resources. So basically, these credentials are about already provided access grants, that haven&#39;t been turned into access tokens yet. Examples of such credentials which can be turned in for access tokens:</div>
</div><div><br></div><div>    - authorization code: This represents an access grant from the end user. Instead of receiving an access token when the grant was issued, you got this code, which basically is a credential that says &quot;This person is allowed to access the protected resource, but we haven&#39;t given him a proper token to do that yet&quot;. The token endpoint is for turning one of these into a token.</div>
<div>    - refresh token: in case your access token has been used up or expired, one refresh token can be exchanged for one access token</div><div>    - assertion: this is basically just a pair of opaque strings (a type and a value); it&#39;s used for tying OAuth in with existing systems. Hence, this is deliberately vague.</div>
<div>    - user credentials: this is the classic username/password. It&#39;s a bit silly to use this; the only advantage is that you can limit which servers need access to these credentials.</div><div><br></div><div>The key thing to remember is: token endpoints let you trade in some credentials that prove you&#39;re supposed to have access for a token that actually *gives* you that access.</div>
<div><br></div><div>Since people asked for more detail as to which data exactly needs to be passed to the Realm (yes, even now that I know what the Realm actually does). This is basically all of the data in the token endpoint&#39;s response. The response contains the following data, in JSON format: (explanations of what each thing is in the following paragraphs)</div>
<div><div>    - the access token (an ascii string, mandatory)</div><div>    - the expiration time (optional)</div><div>    - the refresh token (another ascii string, similar to the access token, optional)</div><div>    - scope (an ascii string consisting of a set of space-separated words, optional)</div>
<div><br></div><div>Optional here does not really mean &quot;at my option&quot; but &quot;occasionally required&quot;, so it is necessary that all four can be passed to the IRealm at the same time. Furthermore, it&#39;s impossible to use the Mind for some of them, because ICredentialsCheckers never see the Mind, and all of that data (access token, refresh token, expiration time, scope) are only ever visible to the ICredentialsChecker.</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Again, the access token is something you use to actually access a protected resource. The refresh token is something you use to get a new token when your old one expires or is used up. Defining the scope properly is hard, it&#39;s deliberately vague in the spec as well; it&#39;s a set of strings that determine what you can do with your shiny new access token. For example, for Facebook, the scope might be &quot;name friends likes&quot; for a token that allows someone to access your name, your list of friends and what you like, but not your pictures, gender, date of birth. These values are not determined by the spec, and you can just make some up for your service.</div>
</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Also, to clear up a misunderstanding:</div><div>&gt; (and furthermore, why is anybody responsible for &quot;requesting the new token&quot; in the first place?  why do any new tokens ever need to be requested on the service provider&#39;s side of things?)</div>
<div>Yes, sorry, that was a poorly chosen verb. I should have just said &quot;creates a new token&quot;; I didn&#39;t, because typically token creation and storage happens somewhere else in a centralized place (hence, this code *requests* it).</div>
</div><div><br></div></div><div><br></div><div>Does that help?</div><div>Laurens</div>