I noticed that the server war provides a servlet mapping under three roots:
admin -- applies an auth check which requires a previously issued bearer token, so it seems to be designed to protect access to the resource API (for registering resource servers and clients).
oauth2 -- applies an authentication check specifically to the authorize resource, so it appears to be designed to handle the RO authentication required by section 3.1 of the spec.
v1 -- just provides raw access.
However the code behind the various resources makes assumptions about which filters will actually be applied. For example, the resource manager code (such as ResourceServerResource.java) expects that the access will have been authorized and thus a verified token will be available. This isn't in this case, so the result is an NPE on any access. What is the intended purpose of the v1 mapping?
A related question is why all 3 mappings actually give you access to the same resource URIs (so you could issue "admin/authorize" or "oauth2/resourceServer" as valid URIs, though they may or may not work properly). Seems like a more precise set of mappings would be better to avoid confusion and spurious errors (or accidental success).
I noticed that the server war provides a servlet mapping under three roots:
However the code behind the various resources makes assumptions about which filters will actually be applied. For example, the resource manager code (such as ResourceServerResource.java) expects that the access will have been authorized and thus a verified token will be available. This isn't in this case, so the result is an NPE on any access. What is the intended purpose of the v1 mapping?
A related question is why all 3 mappings actually give you access to the same resource URIs (so you could issue "admin/authorize" or "oauth2/resourceServer" as valid URIs, though they may or may not work properly). Seems like a more precise set of mappings would be better to avoid confusion and spurious errors (or accidental success).