<div dir="ltr">eu sabia q tinha mais uma etapa, não lembrava desse detalhe.<div><br></div><div>Valeu eden.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/6 Eden Cardim <span dir="ltr"><<a href="mailto:eden@insoli.de" target="_blank">eden@insoli.de</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>>>>> "Tiago" == Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>> writes:<br>


<br>
</div>    Tiago> isso é feito server side. Oauth, SE NAO ME ENGANO, quando<br>
    Tiago> vc faz<br>
<br>
    Tiago> 1 - tenta logar no youtube<br>
<br>
    Tiago> ele ve q vc nao tem cookie de sessao e manda pra<br>
    Tiago> <a href="http://accounts.google.com" target="_blank">accounts.google.com</a> e na url tem alguma indicação que vc<br>
    Tiago> veio do youtube (um redirect_url=xxx por exemplo).<br>
<br>
    Tiago> 2- vc loga no <a href="http://accounts.google.com" target="_blank">accounts.google.com</a><br>
<br>
    Tiago> 3- google the redireciona pra url xxx do youtube e recebe<br>
    Tiago> uma chave y<br>
<br>
    Tiago> 4- o youtube recebendo esse redirecionamento verifica<br>
    Tiago> server side se a chave y é valida. se sim ele inicia a<br>
    Tiago> sessao.<br>
<br>
    Tiago> é server side pq vc tem um par de chaves criptograficas pra<br>
    Tiago> utilizar nesse handshake interno.<br>
<br>
Dei uma revisada na especificação e você realmente está correto, isso<br>
é OAuth com implicit grant e não o tipo mais comum, o authorization<br>
code grant, vide <a href="http://tools.ietf.org/html/rfc6749#section-1.3.2" target="_blank">http://tools.ietf.org/html/rfc6749#section-1.3.2</a><br>
<br>
O implicit grant é viável pelo fato dos dois serviços pertencerem à<br>
mesma organização, assim, se o token for exposto a um terceiro, ambos<br>
os serviços podem conferir a validade do mesmo via handshake no<br>
backend, pra conferir se a pessoa que usou o token no <a href="http://youtube.com" target="_blank">youtube.com</a> está<br>
realmente autenticada no <a href="http://accounts.google.com" target="_blank">accounts.google.com</a> e se a conta dela está<br>
autorizada a usar esse token, antes de liberar o acesso.<br>
<br>
O authorization code grant, que é a modalidade mais comum em apis,<br>
etc. faz uma troca de tokens com serviços de terceiros para que o<br>
token de acesso final não fique exposto no browser.<br>
<div class="im HOEnZb"><br>
--<br>
Eden Cardim -- Insolide Soluções de TI Ltda.<br>
<a href="tel:%2B55%2011%209644%208225" value="+551196448225">+55 11 9644 8225</a><br>
<a href="http://insoli.de" target="_blank">http://insoli.de</a><br>
</div><div class="HOEnZb"><div class="h5">=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tiago B. Peczenyj<br>Linux User #405772<br><br><a href="http://about.me/peczenyj" target="_blank">http://about.me/peczenyj</a>
</div>