<div dir="ltr">I was thinking this morning that a decent approach might be to bounce the user to the system web app, have them log in and then have the web app "redirect" them to  URL with an intent in it so that the phone would open the app again and pass a token/cookie value in that it could use to make API calls.<div><br></div><div>That Ping article says that's the old/broken way to do it, though! </div><div><br></div><div>It seems like the most logical approach would be to use something like the OAuth2 Password grant (<a href="http://oauthlib.readthedocs.io/en/latest/oauth2/grants/password.html">http://oauthlib.readthedocs.io/en/latest/oauth2/grants/password.html</a>) where I'd take credentials from the user in the native app and exchange them for an access token which expires after X seconds.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 4, 2017 at 11:41 AM Marc Boorshtein <<a href="mailto:mboorshtein@gmail.com">mboorshtein@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://developer.pingidentity.com/en/resources/napps-native-app-sso.html" class="gmail_msg" target="_blank">https://developer.pingidentity.com/en/resources/napps-native-app-sso.html</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Does not apply to QT5 applications, but might be useful in other settings.</div><span class="m_6974305813016591454HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></font></span></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Issue I see with this is while it works, seems to break the way openid connect is supposed to work.  you're not supposed to move the tokens between agents (in this case the browser and the app).  Should be generating a new token once authenticated that is then transfered via OAuth2 (we had this same discussion over on kubernetes a few weeks back).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But I think the moral of the story is, if you design your app+backend services correctly saml vs openid connect shouldn't matter.</div><div class="gmail_msg"> </div></div></div></div>
--<br class="gmail_msg">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="gmail_msg" target="_blank">users-unsubscribe@shibboleth.net</a></blockquote></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">--<div>Andy Watson</div><div>Make and Build</div></div></div>