Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

[Tatsuya Karino]

> However, do you need OAuth in such situation?

> Same-site cookie seems much simpler there.

yeah, right. For a 1st party application, we don't need to use the
delegation of privilege.

Using Same-site cookies is simple.

But I also think if the company provide their APIs to 3rd party
applications,

it is a little heavy to provide two types of AuthN/AuthZ system (for 1st
party and for 3rd party).

Providing same AuthN/AuthZ system to 1st and 3rd party is more
sophisticated, I think.

But in this case, the feature that can be used only for 1st party (my first
mail example) is not acceptable lol.


By the way, I also wonder what is the better option to use OAuth2.0 on SPA
Client (3rd party) with good UIUX.

In my understanding, there are two options to achieve it.

1. Using response_momde=web_message or 2.Using Refresh Token with fixed
maximum lifetime.

But I have a concern on a practical use.

For 1, Some browser could be restricted to send credential cookie to the
authorization server from iframe.

For 2, The Refresh Token must be saved on the browser, but it could be
deleted on 7days in safari.

Is there any workaround? or Is there any misunderstanding on my concerns?


2021年3月13日(土) 13:05 Nov Matake :

> Your mechanism seems work fine.
>
> However, do you need OAuth in such situation?
> Same-site cookie seems much simpler there.
>
> iPadから送信
>
> 2021/03/13 0:45、Tatsuya Karino のメール:
>
> 
>
> Hi all,
>
> I'm looking for the specification to generate a new Access Token with
> authentication session in a Single Page Application with good User
> Experience. There is a draft, OAuth 2.0 Web Message Response Mode
> . And it's
> called silent authentication on Auth0. When I read the draft, I got a
> question about verifying the receiver of an auth code.
>
> The summary of the flow with response_mode=web_message is like this,
>
> + The client (main window) creates an invisible iframe.
>
> + An authorize request is sent to authorization server with authentication
> session on the cookie.
>
> + The authorization server checks the authentication session and user
> consent .
>
> + If it is ok, the authorization server returns an auth code with
> Javascript code.
>
> + The auth code is delivered to the client (main window) by Web Message on
> the Javascript code.
>
> I understood this specification like that,
>
> Returning auth code to the browser itself is acceptable.
>
> What we want to prevent is sending the auth code to a malicious client.
>
> It is prevented by restricting receiver of auth code by Web Message in
> this spec.
>
> It is same for other response_mode.
>
> Then I wonder if it is possible to achieve the situation by CORS settings.
>
> For example like this,
>
> + The client (SPA) send an authorize request from Javascript with the CORS
> settings.
>
>   + Access-Control-Allow-Credentials: true
>
> + The authorize request is sent with authentication session on the cookie.
>
> + The authorization server checks the authentication session and user
> consent.
>
> + If it is ok, the authorization server returns a response that includes
> auth code with CORS Headers.
>
>   + Access-Control-Allow-Origin: domain specified for each client like
> redirect_uri.
>
>   + Access-Control-Allow-Credentials: true
>
> + The browser checks the origin if the domain is same with that one used
> for client application.
>
>   + If the preflight request is happened, this check will be done before
> generating auth code.
>
> + If it is ok, the client receives the auth code.
>
>
> I feel that the use case is quite small because authorization server and
> client have to be provided on the same eTLD+1 at least for the safari. But
> the implementation would be very simple, so it could be used if the company
> has 1 authorization server and multi clients.
>
> Is there any specification like that? or What kind of security issues are
> there in the flow?
>
> Thanks!
>
> --
> Tatsuya Karino
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Tatsuya Karino
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

[Nov Matake]

Your mechanism seems work fine.

However, do you need OAuth in such situation?
Same-site cookie seems much simpler there.

iPadから送信

> 2021/03/13 0:45、Tatsuya Karino のメール:
> 
> 
> Hi all, 
> 
> I'm looking for the specification to generate a new Access Token with 
> authentication session in a Single Page Application with good User 
> Experience. There is a draft, OAuth 2.0 Web Message Response Mode. And it's 
> called silent authentication on Auth0. When I read the draft, I got a 
> question about verifying the receiver of an auth code.
> 
> The summary of the flow with response_mode=web_message is like this,
> + The client (main window) creates an invisible iframe.
> + An authorize request is sent to authorization server with authentication 
> session on the cookie.
> + The authorization server checks the authentication session and user consent 
> .
> + If it is ok, the authorization server returns an auth code with Javascript 
> code.
> + The auth code is delivered to the client (main window) by Web Message on 
> the Javascript code.
> 
> I understood this specification like that,
> Returning auth code to the browser itself is acceptable.
> What we want to prevent is sending the auth code to a malicious client.
> It is prevented by restricting receiver of auth code by Web Message in this 
> spec.
> It is same for other response_mode.
> 
> Then I wonder if it is possible to achieve the situation by CORS settings.
> 
> For example like this,
> + The client (SPA) send an authorize request from Javascript with the CORS 
> settings.
>   + Access-Control-Allow-Credentials: true
> + The authorize request is sent with authentication session on the cookie.
> + The authorization server checks the authentication session and user consent.
> + If it is ok, the authorization server returns a response that includes auth 
> code with CORS Headers.
>   + Access-Control-Allow-Origin: domain specified for each client like 
> redirect_uri.
>   + Access-Control-Allow-Credentials: true
> + The browser checks the origin if the domain is same with that one used for 
> client application.
>   + If the preflight request is happened, this check will be done before 
> generating auth code.
> + If it is ok, the client receives the auth code.
> 
> 
> I feel that the use case is quite small because authorization server and 
> client have to be provided on the same eTLD+1 at least for the safari. But 
> the implementation would be very simple, so it could be used if the company 
> has 1 authorization server and multi clients.
> 
> Is there any specification like that? or What kind of security issues are 
> there in the flow?
> 
> Thanks!
> 
> -- 
> Tatsuya Karino
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization handover from mobile app to website

[Nov Matake]

You can make your app an OIDC self-issued IdP for your website.

One of my clients are using the mechanism for Native App SSO, where an OIDC 
self-issued IdP embedded in the Native App is acting as IdP for the backend IdP 
server.

Unfortunately I have no english document now, but this slide describes the 
mechanism.
https://speakerdeck.com/rtechkouhou/openid-connect-self-issued-idpwoying-yong-sitasingle-sign-onfalseshi-zhuang

iPadから送信

> 2021/03/13 3:24、SOMMER, DOMINIK のメール:
> 
> 
> Hi all,
>  
> we have recently launched a mobile app that uses our website’s login and 
> authorization code flow to authenticate and authorize user access (following 
> RFC8252).
>  
> However, not all of our website features are natively ported to the app 
> itself. Some are only available on the website in logged-in state. That’s why 
> we implemented an authorization handover mechanism based on one-time login 
> codes: This allows the app (in logged-in state) to open a web view and hand 
> over authentication & authorization, effectively logging the user in on the 
> website. This achieves a seamless experience for the user without 
> compromising on security.
>  
> We came up with this mechanism after researching for prior practice, but we 
> couldn’t find anything applicable for this scenario.
>  
> Hence, three questions to the list:
> 1. Did we miss anything in our research? Is there a common best practice 
> available?
> 2. If the answer to 1. is “No”, would the working group appreciate an RFC 
> draft describing the solution we came up with? (We’d be eager for comments to 
> make it even more secure J )
> 3. If the answer to 2. is “Yes”, can someone point me to documentation on the 
> procedure, if such exist?
>  
> Thanks for your support and
> best regards,
> Dominik
> 
> Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt 
> am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 
> 116409
> Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization handover from mobile app to website

[George Fletcher]

I can't find a record of sending this to the list, but I wrote this ID 
back in 2013 and we've implemented it. At the time I did vet it with a 
few people. Hopefully it might be helpful :)


Thanks,
George

On 3/12/21 1:18 PM, SOMMER, DOMINIK wrote:


Hi all,

we have recently launched a mobile app that uses our website’s login 
and authorization code flow to authenticate and authorize user access 
(following RFC8252).


However, not all of our website features are natively ported to the 
app itself. Some are only available on the website in logged-in state. 
That’s why we implemented an authorization handover mechanism based on 
one-time login codes: This allows the app (in logged-in state) to open 
a web view and hand over authentication & authorization, effectively 
logging the user in on the website. This achieves a seamless 
experience for the user without compromising on security.


We came up with this mechanism after researching for prior practice, 
but we couldn’t find anything applicable for this scenario.


Hence, three questions to the list:

1. Did we miss anything in our research? Is there a common best 
practice available?


2. If the answer to 1. is “No”, would the working group appreciate an 
RFC draft describing the solution we came up with? (We’d be eager for 
comments to make it even more secure J)


3. If the answer to 2. is “Yes”, can someone point me to documentation 
on the procedure, if such exist?


Thanks for your support and

best regards,

Dominik


Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, 
Frankfurt am Main, Registereintragung / Registration: Amtsgericht 
Frankfurt am Main HRB 116409
Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver 
Schmitt




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Identity Standards Architect
Verizon Media Work: george.fletc...@oath.com
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

Title: Draft: OAuth2 Bootstrap to web session - draft 03



 TOC 

DraftGFF. Fletcher, Ed.
 AOL
 May 24, 2013

OAuth2 Bootstrap to web session - draft 03

Abstract

This document describes a process that allows a client to seamlessly transition 
 the user from an authenticated state in a native application, to an authenticated 
 state in a web browser.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1. 
Introduction
1.1. 
Roles
1.2. 
Scopes
1.3. 
Protocol Flow
1.4. 
Terminology
2. 
Bootstrap Token
2.1. 
Refresh Token Authorization Grant
2.2. 
Assertion Framework Authorization Grants
2.3. 
Bootstrap Token Request Processing Rules
3. 
Web Session endpoint
4. 
Security Considerations
5. 
Normative References
§ 
Author's Address




 TOC 
1. 
Introduction

In order to provide a good user experience it is necessary at times to "share"
  an authentication state across disparate environments. For example, a desktop
  utility that shows the user a list of their last N mail messages, and when the
  user selects one of the mail messages, opens a browser logging the user into
  their mail account on the web.

This document defines a process based on OAuth2 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] to enable this functionality.


 TOC 
1.1. 
Roles

This specification uses the 'client' and 'authorization server' roles 
 from the OAuth2 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] specifcation. In addition
 to these two roles, this specification also identifies the role of the
 

web application
The destination web application where the
   user will be seamlessly logged in.


  


 TOC 
1.2. 
Scopes

This specification defines an additional scope that MUST be authorized to
 the client in order to obtain the bootstrap-token.
 
 

web_session
A scope that provides the client the
   authorization to obtain a bootstrap-token


  


 TOC 
1.3. 
Protocol Flow


   +-+
   | |
   | |
   +--(C)--+Client   |
   |   | |
   |   | |
   |   +++
   |   

[OAUTH-WG] Authorization handover from mobile app to website

[SOMMER, DOMINIK]

Hi all,

we have recently launched a mobile app that uses our website’s login and 
authorization code flow to authenticate and authorize user access (following 
RFC8252).

However, not all of our website features are natively ported to the app itself. 
Some are only available on the website in logged-in state. That’s why we 
implemented an authorization handover mechanism based on one-time login codes: 
This allows the app (in logged-in state) to open a web view and hand over 
authentication & authorization, effectively logging the user in on the website. 
This achieves a seamless experience for the user without compromising on 
security.

We came up with this mechanism after researching for prior practice, but we 
couldn’t find anything applicable for this scenario.

Hence, three questions to the list:
1. Did we miss anything in our research? Is there a common best practice 
available?
2. If the answer to 1. is “No”, would the working group appreciate an RFC draft 
describing the solution we came up with? (We’d be eager for comments to make it 
even more secure ☺ )
3. If the answer to 2. is “Yes”, can someone point me to documentation on the 
procedure, if such exist?

Thanks for your support and
best regards,
Dominik

Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt am 
Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 
116409
Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Re-creation of Access Token on Single Page Application

[Tatsuya Karino]

Hi all,

I'm looking for the specification to generate a new Access Token with
authentication session in a Single Page Application with good User
Experience. There is a draft, OAuth 2.0 Web Message Response Mode
. And it's called
silent authentication on Auth0. When I read the draft, I got a question
about verifying the receiver of an auth code.

The summary of the flow with response_mode=web_message is like this,

+ The client (main window) creates an invisible iframe.

+ An authorize request is sent to authorization server with authentication
session on the cookie.

+ The authorization server checks the authentication session and user
consent .

+ If it is ok, the authorization server returns an auth code with
Javascript code.

+ The auth code is delivered to the client (main window) by Web Message on
the Javascript code.

I understood this specification like that,

Returning auth code to the browser itself is acceptable.

What we want to prevent is sending the auth code to a malicious client.

It is prevented by restricting receiver of auth code by Web Message in this
spec.

It is same for other response_mode.

Then I wonder if it is possible to achieve the situation by CORS settings.

For example like this,

+ The client (SPA) send an authorize request from Javascript with the CORS
settings.

  + Access-Control-Allow-Credentials: true

+ The authorize request is sent with authentication session on the cookie.

+ The authorization server checks the authentication session and user
consent.

+ If it is ok, the authorization server returns a response that includes
auth code with CORS Headers.

  + Access-Control-Allow-Origin: domain specified for each client like
redirect_uri.

  + Access-Control-Allow-Credentials: true

+ The browser checks the origin if the domain is same with that one used
for client application.

  + If the preflight request is happened, this check will be done before
generating auth code.

+ If it is ok, the client receives the auth code.


I feel that the use case is quite small because authorization server and
client have to be provided on the same eTLD+1 at least for the safari. But
the implementation would be very simple, so it could be used if the company
has 1 authorization server and multi clients.

Is there any specification like that? or What kind of security issues are
there in the flow?

Thanks!

-- 
Tatsuya Karino
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: Webex meeting changed: OAuth WG Interims

[Rifaat Shekh-Yusef]

Forwarding the meeting invitation because we added one more session on
April 26.



-- Forwarded message -
From: Web Authorization Protocol Working Group 
Date: Fri, Mar 12, 2021 at 9:07 AM
Subject: Webex meeting changed: OAuth WG Interims
To: 




You changed the Webex meeting information.


When it's time, start your Webex meeting here.


Occurs every Monday effective Monday, March 15, 2021 until Monday, April
26, 2021 from 12:00 PM to 1:00 PM, (UTC-05:00) Eastern Time (US & Canada)
12:00 PM  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr

Start meeting


*More ways to join:*

*Join from the meeting link*
https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b

*Join by meeting number*
Meeting number (access code): 185 067 2252
Meeting password: nCgm6qTjH45

*Tap to join from a mobile device (attendees only)*
+1-650-479-3208,,1850672252## <%2B1-650-479-3208,,*01*1850672252%23%23*01*>
Call-in toll number (US/Canada)

*Join by phone*
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in numbers


*Join from a video system or application*
Dial 1850672...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

*Join using Microsoft Lync or Microsoft Skype for Business*
Dial 1850672252.i...@lync.webex.com

If you are a host, click here

to view host information.

Need help? Go to https://help.webex.com


invite.ics
Description: application/ics


Webex_Meeting.ics
Description: application/ics
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth WG Interim Meetings Schedule - March/April 2021

[Rifaat Shekh-Yusef]

All,

Here is the updated list of our upcoming interim meetings:

*March 15*
*DPoP* – Brian
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

*March 22*
*OAuth 2.1* – Dick/Aaron
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

*March 29*
*Client Intermediary Metadata* – Aaron
https://datatracker.ietf.org/doc/draft-parecki-oauth-client-intermediary-metadata/
*Multi-Subject JWT* – Rifaat
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

*April 5*
*RAR* – Torsten
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

*April 12*
*Security BCP *– Daniel
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

*April 19*
*Identity Use Cases in Browser Catalog* – Vittorio/George
https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/

*April 26*
*TMI BFF* – Vittorio/Brian
https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/



*Webex meetings link:*
https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth