<div dir="ltr"><div><br><span style="color:rgb(33,33,33)">' instead of the 302 being "</span><a href="https://mysp.mydomain.com/" class="gmail_msg" target="_blank" style="outline:transparent solid 1px">https://mysp.mydomain.com/..</a><span style="color:rgb(33,33,33)">.</span><span style="color:rgb(33,33,33)">" the redirect is "myregisteredapp://..."<span class="inbox-inbox-Apple-converted-space"> '</span></span></div><div><span style="color:rgb(33,33,33)"><span class="inbox-inbox-Apple-converted-space"><br></span></span></div><div><span style="color:rgb(33,33,33)"><span class="inbox-inbox-Apple-converted-space">That's exactly what I was thinking.  Since I have more control over the SP than the IdP I was thinking of doing that redirect there, though.</span></span></div><div><span style="color:rgb(33,33,33)"><span class="inbox-inbox-Apple-converted-space"><br></span></span></div>Let me back up a step... What I have is an existing web app (SAML SP, right?) that is currently set up to use the (Shibboleth) IdP and authn/authz its users.  What I'd like to add to the mix is an android application that can make API calls to the web app but only if people are authenticated and authorized to do so.<div><br></div><div>So the android app needs to present something to the SP like a browser would present cookies.  If the user isn't authn/authz'd currently we'd open a browser, point it at the SP and complete the login flow (<a href="https://wiki.shibboleth.net/confluence/display/CONCEPT/FlowsAndConfig">https://wiki.shibboleth.net/confluence/display/CONCEPT/FlowsAndConfig</a>) but at the end of step 6 we'd issue another 302 to the Intent of the Android or iOS app to get them back into the native application...</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 4, 2017 at 2:01 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/4/17, 1:48 PM, "users on behalf of Andrew Watson" <<a href="mailto:users-bounces@shibboleth.net" class="gmail_msg" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:andrew.watson@makeandbuild.com" class="gmail_msg" target="_blank">andrew.watson@makeandbuild.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
>    Ok, so what is the best approach to authenticate/authorize users of a mobile application against a Shibboleth IDP? It<br class="gmail_msg">
> doesn't look like it supports AppAuth, OpenID Connect or OAuth2...<br class="gmail_msg">
<br class="gmail_msg">
Unless I'm totally confused, AppAuth is not something the IdP supports or doesn't support, it's a detail of the mobile platform to mediate the browser interaction to improve the user experience.<br class="gmail_msg">
<br class="gmail_msg">
When you secure services with OAuth or cookies, you run an *SP* (in SAML parlance). The SP is the thing issuing the token(s) back to your application. It needs to authenticate the user. That's done with WebSSO and a browser, to interact with an IdP. The IdP is not issuing the tokens. If you don't want to operate a SAML SP, then you'd have a problem, but there are plenty of simple ways to do that if all you need to protect is a token issuing endpoint, the Shibboleth SP included.<br class="gmail_msg">
<br class="gmail_msg">
This whole thread is about the interactions between your app and the browser client. That is where all these new tricks come into play and the part that's rapidly evolving.<br class="gmail_msg">
<br class="gmail_msg">
-- Scott<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<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><br class="gmail_msg">
</blockquote></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>