Are you talking about the `/oauth2.0/profile` URL? Yes, then it will be the client who calls it. There are 2 scenarios:
 - The client is calling through the *implicit* or the *authorization_code* grant type, which supports redirects. the CASTGC stored from the resource owner logging in should be sufficient to allow access to the `/oauth2.0/profile` endpoint.
 - The client is calling through the *password* or *client_credentials* grant type, which does not redirect (and therefore no cookie storage). This is a reason why these aren't supported yet; we need to be able to secure this endpoint for those clients and grant types. Since the profile resource is not in the OAuth spec I assumed it was safe to assume that these types of clients would not use it.

Either way the `/oauth2.0/profile` is a resource owned by the Cas user, so it made sense to me to identify it as a Cas-protected resource. There's probably a better way to do it.