Let’s pretend we are a website “app” – trying to get rights and tokens to use at a Realty ODATA API.
the device, sending a first message to get authorized as an app.
The app is assumed to using a web browser, so our OAUTH AS does something a bit like an openid connect flow is supposed to do – and shows (for this AS tenant) its set of IDPs:
Show a configurable by tenant subset of IDPs configured into the AS, where the AS is itself often an OAUTH client (with client_id and client_secret)
We have to pass the core challenge at wordpress.com
which gets us a unique bit of OAUTH in the wordpress world – which is to select a wordpress site:
This done, we are directed to that site – which as a non-cloud membership system:
this is the blog site with some locally-registered blog posts (and we may want to use ITS API)
Since our websso/openid-connect style middleman IS the app, it consume the access token (“iesmrDXy4h*GTblP9D^1iE92ab3(n6GdcbU0PkvynxUWDGBmGoq6bNa3)ViXB)NW” and uses it to consult the ME API endpoint. From this, the linking experience is introduced:
Now, this showed that the access token “associated with” the jetpack-powered site is still viable at the ME interfaces offered by wordpress.com. Is it actually valid at the jetpack site, however?
Our OAUTH AS doesn’t answer that, so we have to use CURL:
wordpress.com API endpoint
C:\>curl.exe -k -H “authorization: Bearer HERE” “https://public-api.wordpress.com/rest/v1/sites/jetpack.azurewebsites.net?pretty=1″
my jetpack.azurewebsites.net API endpoint and some blog post listings:
and indeed our blog post is at http://wp.me/s3CQ9u-51
What is interesting is that the endpoint is still wordpress.com (which presumably proxies requests to the self-hosted server in realtime, or fullfills the API from a local cache pulled from said server).
Perhaps its time I pulled down the azure websites hosted site into my own webmatrix on my PC – so I do some proper spying on whats going on!