This isn't possible, for simplicity reasons.
Right now there are a few states a user can get into w.r.t. authentication:
- logged in, app not authorized
- need to authorize app
- app not in app tab
- logged in, app authorized
- not logged in, app not authorized
- need to login, then authorize app
- app not in app tab
- not logged in, app authorized
- need to login, then no prompt
- app in app tab
To support a "logged out of app" state, we'd need to add
- logged in, app authorized but logged out
- need to login (despite being logged in), then no prompt
- app in app tab
This would be more than a bit confusing. This would be the only case where "logged in + in app tab" still results in some sort of prompt. It would also further complicate our (already fairly complex) login story; and may be confused with the "add a credential" case, since that's the only other time we show logged in users the OpenID buttons.
I think it's important to think about what you're trying to do with this, you can probably do it without any changes to our authentication scheme.
Want to force your app to require the user explicitly approve it again
Uninstall it, using /apps/{authTokens}/de-authenticate. You'll get an approve/reject dialog next time.
Want to force the user to "login" explicitly to the app
Whenever a user logs out, destroy all your access tokens via /acccess-tokens/{accessTokens}/invalidate. Have an explicit UI for starting the app back up.
Basically, the user won't be prompted (unless they're logged out of stackexchange.com) by the API, but you can shove you're own "are you sure?" prompt in front of them. The app stays in their app tab, and there's no approve/reject to click through.
Don't want any access tokens laying around while the app isn't running
Destroy the access tokens as above, but immediately start an authentication flow on app start. There will only be a prompt if the user isn't logged into stackexchange.com.
I suspect the second option is the one you want. Actually forcing users back through the OpenID process seems a bit... odd, especially since if they still have all their cookies there won't be any username/password fields presented to them at all.