Nie nutne, teda v komercnom svete je bezne, ze davas aj offline pristup. Napriklad, ze ti niekto chodi kukat do schranky aj ked mu vzdy nedavas znova novy token.
Zvysok by som suhlasil.
Neviem nakolko riesi standardizacia aj procesy, lebo tam vidim velke prekazky. Technikalie ci to bude soap/rest taky ci onaky je “open data vs. ontologie” diskusia v ruzovom - je mi to takmer jedno, hlavne nech to vieme co najskor a rozumne pouzivat. Vsetko navyse je plus.
Toho sa az tak nebojim. Len sa bojim ze to nebude stat tolko co amazon API Management - Amazon API Gateway - AWS alebo Kong https://getkong.org/ 
Mas priklad? Lebo tuto je google oauth playground OAuth 2.0 Playground pripadne openid connect OpenID Connect | Authentication | Google for Developers - teraz neviem ci myslis vizualne alebo technicky.
Pri STS napriklad na UPVS sluzbach (s plnou vaznostou to sem davam ako pekny priklad ) je to jasne, token ktory dostanes vies overit, ze ide od STS sluzby (je podpisany), vidis na co bol vydany (endpointy) a vidis onbehalfof (za koho). Toto sa riesi teda na strane vydavania tokenu. Nasledne samotne agendove pristupove prava riesis u seba - to aj tak asi nema zmysel posuvat inam lebo to bude najskor naviazane aj na biznis logiku ktoru vytrhavat z agendy je blbost (vid formulare). – TODO: treba overit ako funguje pri openidconnect/oauth.
Opat je prikladom UPVS - dev prostredie je vystavene do internetu. 
Co by mu vsak pomohlo su nejake dummy data na vsetky endpointy (ktore netreba pytat od sluzby), lahsie ziskanie pristupu, kvalitnejsia dokumentacia na webe a nech sa tam da vyhladavat. word dokumenty na “FTP” fakt nie su nic moc.
Podla mna je jedina cesta velmi neoddelovat od seba ani dev infrasturkturu ani dokumentaciu pre public a G2G cast. Akonahle sa to stane, tak public cast nebude “first-class citizen”.