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

Nov Matake <> Sat, 13 March 2021 04:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D10F93A1490 for <>; Fri, 12 Mar 2021 20:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X0kUO0GEBn3n for <>; Fri, 12 Mar 2021 20:00:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B35333A148C for <>; Fri, 12 Mar 2021 20:00:02 -0800 (PST)
Received: by with SMTP id ga23-20020a17090b0397b02900c0b81bbcd4so11665562pjb.0 for <>; Fri, 12 Mar 2021 20:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ucIdLtUVZ/ike8UuEdJirQRu4KFdGLYFGrtyNn8Qpo4=; b=D7VZDBxeAw0IX92filGSVchJv4NonZc4YnqfxGUICxtYCMM0tkIvo3rU3x/BvHRBum iZI7rEYdB6f6olhItt2AKoLOduZakxCkTGe35iM7R62zGOyIW9acAFxHOH5a5Y7bvqUI I+LRfMd8Ozbbv4zmpYvD80x8wjE8oUERpqcVpYQdynFsMw0rcX/vjQGcT5xYsK58UTdb oOpxkbXPopFRPGkfJo0CgmQDr0TjknB5tISTl8GNkDUsPMfBfjMNJopHXnlwdMlgmA2U U/zCIkg1ojn3ONgS5eZTr8jCy/2msYyS9Iu+rDKJ/3YTCcCJjBRTosGQVyNBGwUDh6iL zuqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ucIdLtUVZ/ike8UuEdJirQRu4KFdGLYFGrtyNn8Qpo4=; b=cQ+ukDwAM4h8erAKtCvOWT1jo8M+Y+lsoih+DkAmq46YmJCeVbLuLetBccQqpKHg0H j0Ibk9EcBKzLATG9KLfk3V9fpB75ddmEIIib8XdFR1qg/rb3KtYCFaVunTQe60GrCqD1 5WyXJ9k92coJhC3tWsTYXdm4xIgd8J8efvvPZlzmh+vcrSSO8/xtgFSCIVC8nO76Xy3o 5wMbvocXhhoKiIgdv15nq0zbobTkeUnlE0F+xMMVCHaYVkXRaKmNWMfTm+Dgi46ESlZl pLWbStx/iUssNEv4CMkZahI8o3fUCp+MghiXGem96laaFWBPQqlDvbjb6fwoXikSYhA7 CemQ==
X-Gm-Message-State: AOAM533OKBOQuwLBRjFf3+qlDRzM59uEXxt5TjX/knGma4QUuetpR8ba BBZCxQ1ErUTvoma4sEtGFy5KdKIt7VnRhQ==
X-Google-Smtp-Source: ABdhPJzQEz4fbv9Vc8aGWIhT+ydIQ9JcSvaZvRI8vF2gxOu/b13WxoEng/M50hOnlseXmnBXTM7a9Q==
X-Received: by 2002:a17:90a:d3d8:: with SMTP id d24mr1646159pjw.28.1615608000991; Fri, 12 Mar 2021 20:00:00 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e1sm3421867pjt.10.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Mar 2021 20:00:00 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-C47F30F3-FA5A-48A4-8C18-1146B6EAD801"
Content-Transfer-Encoding: 7bit
From: Nov Matake <>
Mime-Version: 1.0 (1.0)
Date: Sat, 13 Mar 2021 12:59:57 +0900
Message-Id: <>
References: <>
In-Reply-To: <>
X-Mailer: iPad Mail (18D61)
Archived-At: <>
Subject: Re: [OAUTH-WG] Authorization handover from mobile app to website
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Mar 2021 04:00:06 -0000

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.


> 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