IBM Security Verify

 View Only
Expand all | Collapse all

OAuth Device authorization code flow and id_token generation

  • 1.  OAuth Device authorization code flow and id_token generation

    IBM Champion
    Posted Fri October 16, 2020 02:28 AM
    Hello everybody,

    I am struggling to get the Device Authorization code flow to generate an id_token at the same time that the access and refresh token pair.
    It is something that works flawlessly with the other oauth flows, but I'm not able to make it work with this particular flow.

    Am I missing something in my initial request ?
    curl -H "Accept: application/json" -X POST "https://mydomain/mga/sps/oauth/oauth20/device_authorize?response_type=id_token" -d "client_id=myClientId&scope=openid&response_type=id_token"​

    Or am I missing something in the polling request done by the smart device ?

    curl -H "Accept: application/json" -X POST "https://mydomain/mga/sps/oauth/oauth20/token" -d "client_id=myClientId&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code={device_code}"



    Thank you for any pointer to the correct way to have ISAM generate access + refresh + id_token in the case of this particular OAuth flow



    ------------------------------
    André Leruitte
    ------------------------------


  • 2.  RE: OAuth Device authorization code flow and id_token generation

    Posted Fri October 16, 2020 05:31 AM
    Hi André,

    I have re-created your findings.

    While I think that the OIDC specification only specifically talks about the authorization_code and implicit flows, it seems logical that you should be able to obtain an id_token using any OAuth 2.0 flow.  Indeed, I was able to retrieve an id_token using the ROPC flow using this request:

    curl -k -H "Accept: application/json" -X POST "https://www.iamlab.ibm.com/mga/sps/oauth/oauth20/token" -d "client_id=test&client_secret=Passw0rd&grant_type=password&username=emily&password=Passw0rd&scope=openid"

    Like you, I was NOT able to retrieve an id_token using the device code flow - despite including scope=openid and response_type=id_token wherever I could.  My guess is that the implementation just doesn't allow it (although someone with more knowledge will have to confirm).

    If we assume it's NOT possible, your main alternative is going to be to get an Access Token via the device flow and then use this to call either the introspect or user_info endpoints to get the additional identity information you need.  If you need the identity information as a JWT then there is customization available to get this as response to either introspect or user_info endpoints (basically calling JWT generation from within mapping rule that processes these requests).

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 3.  RE: OAuth Device authorization code flow and id_token generation

    Posted Fri October 16, 2020 07:30 AM
    Hi Jon,


    Yes, it is the current limitation that device flow not generating id_token. I've seen there's an RFE on this.

    ------------------------------
    Adrian Rinaldi Sasmita
    ------------------------------

    Original Message


  • 4.  RE: OAuth Device authorization code flow and id_token generation

    IBM Champion
    Posted Fri October 16, 2020 07:41 AM
    Hi Jon and Adrian,

    Thanks a lot for taking the time to confirm that it is indeed a limitation of ISAM, and not an error implementing the client side of the oauth flow.

    I had tought of your suggestion Jon as the client application absolutely needs a JWT. I wanted to avoid having to manually generate the JWT at the /userinfo endpoint, but I think that is the only workaround at the moment.
    I will be starting the implementation right now as we need a solution in the coming weeks, the team developping the smarttv application is currently blocked by this issue.

    If there was any way to +1 on the RFE, I would be glad to do it !

    ------------------------------
    André Leruitte
    ------------------------------

    Original Message


  • 5.  RE: OAuth Device authorization code flow and id_token generation

    Posted Mon October 19, 2020 04:13 AM
    Hi André,

    An alternative implementation is one where you customise the device flow. For example you could check if an hybrid flow is being asked for by checking "response_type" and/or "scope" for "openid" during the call to /device_authorize. If so, and when the user is authenticated, then you can build the JWT, associate it to the grant and return it to the caller during the /token call.
    The advantage is that the client only has one call to make - instead of the device flow + introspect/user-info.

    Kind regards, Peter.

    ------------------------------
    Peter Volckaert
    Senior Sales Engineer
    Authentication and Access
    IBM Security
    ------------------------------

    Original Message


  • 6.  RE: OAuth Device authorization code flow and id_token generation

    Posted Tue October 20, 2020 02:45 AM
    Edited by Dries Eestermans Tue October 20, 2020 02:52 AM
    Hi André,

    I opened such an RFE about 2 years ago, when the grant type was first introduced in ISAM:
    "OpenID Connect - onboard OAuth Device Flow as grant type - ID: 127040", maybe you can upvote it, I'm not sure? Either way, I think it's good that it is receiving some attention and may get noticed by IBM.

    One thing I noticed when reviewing this RFE is that I mentioned the following:
    "
    On ISAM 9.0.5, when requesting the 'openid' scope in the initial 'Device Authorization Request', ISAM only returns an 'access_token' and 'refresh_token' (it's missing the 'ID_token').
    Upon then refreshing the access_token, I'm granted an ID_token as well.
    This RFE is aimed at the fact that ID_token should be returned on initial grant response.
    "
    I am not sure whether this is still the case, can you confirm that?

    How I solved it is by re-purposing Leo's JWT Access Token code to generate an ID Token when receiving the "openid" scope, but I believe it be more of a workaround than anything else.

    Kind regards,

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------

    Original Message


  • 7.  RE: OAuth Device authorization code flow and id_token generation

    IBM Champion
    Posted Wed October 21, 2020 03:11 AM
    Hi @Dries Eestermans,

    The issue we are running into is exactly what you mentioned. It is worrying that you already opened an RFE 2 years ago and that it still hasn't be implemented/fixed.

    We could even argue about the fact that it should be an RFE or a bugfix, but it seems that the RFC isn't very precise about the implementation of OIDC in this particular oauth flow.


    For the time being, we are finishing implementing a workaround for generating the needed JWT at /userinfo endpoint.
    We wanted to avoid using the JWT directly as an access token, but maybe we will check later on your proposal @Peter Volckaert


    Anyway, thank you all for your quick replies and for the different workaround tips!


    ​​

    ------------------------------
    André Leruitte
    ------------------------------

    Original Message


  • 8.  RE: OAuth Device authorization code flow and id_token generation

    Posted Wed October 21, 2020 08:54 AM
    Hi,

    Hybrid flows are defined by OIDC and are valid for two types of flows: the "implicit flow" and the "authorization code" flow. See this link: https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth. The flow and the tokens exchanged are determined by the "response_type" and "scope" parameter in the request to the authorization endpoint. The "response_type" parameter is any combination of "token", "id_token" and "code" - it can also be "none". A request for an ID token has to include "openid" in the scope request parameter. This is explained in the spec and also on this nice site: https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660

    Note that hybrid flows are not defined for the device flow - only for the "implicit flow" and the "authorization code" flow. When looking at the device flow RFC (https://tools.ietf.org/html/rfc8628) you'll notice that there is no "response_type" parameter in the request to the device authorization endpoint: there's only client-id, client-secret and an optional scope. The RFC also says that the device authoization endpoint is separated from the OAuth authorization endpoint defined in RFC6749.

    So this is not a flaw or bug in Verify Access; it's simply not foreseen in the OAuth/OIDC specs.
    Of course this doesn't mean that it would be useful to return an id_token in such device flow, and this justifies an RFE for an extra non-standard feature of Verify Access. Looking at the bright side here: thanks to the flexibility of Verify Access you can achieve your desired flow.

    Kind regards, Peter.

    ------------------------------
    Peter Volckaert
    Senior Sales Engineer
    Authentication and Access
    IBM Security
    ------------------------------

    Original Message


  • 9.  RE: OAuth Device authorization code flow and id_token generation

    Posted Wed October 21, 2020 10:28 AM
    Edited by Dries Eestermans Wed October 21, 2020 10:31 AM
    Hi @André Leruitte,

    You would not necessarily use it as an "access token" but rather inject it as an "id_token" in the response (some PoC code I made back then, not sure if it still works):

    if (request_type == "access_token" && grant_type == "urn:ietf:params:oauth:grant-type:device_code") { // ... let id_token = buildIdToken(stsuu); if (id_token != null) { OAuthMappingExtUtils.associate(state_id, "id_token", id_token, false, true); stsuu.addContextAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("id_token" ,"urn:ibm:names:ITFIM:oauth:response:attribute", id_token)); } }​​

    As such, it would inject an "id_token" in the initial grant response and as mentioned, a refresh automatically gives us an id_token, as such it is inside that if statement to only do that when "grant_type=urn:ietf:params:oauth:grant-type:device_code" and not when "grant_type=refresh_token".

    The main problem here in lies in the fact that there is no "ID Token Validation" defined for the Device Authorization Grant, and you could essentially go along as you please (bot h for OP as RP), which is not necessarily the best case since the flow is non-standard and will most likely deviate from provider to provider, like @Peter Volckaert mentioned.

    Authz Code Flow ID Token Validation,
    Implicit Flow ID Token Validation

    Hope this helps.
    ​

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------

    Original Message


  • 10.  RE: OAuth Device authorization code flow and id_token generation

    IBM Champion
    Posted Thu October 29, 2020 06:54 AM
    Hi @Dries Eestermans ,

    We have implemented​ the solution as you suggested, and the behavior is now exactly what we were looking for, in line with the standard behavior on other OAuth flows.

    The "ID token validation" should not be an issue for us as the SmartTV application itself doesn't use the token.
    It sends it to a backend that will perform extended validation of that id_token before allowing the user to go further and start consuming services.


    Thanks you all for your feedbacks once again :)

    ------------------------------
    André Leruitte
    ------------------------------

    Original Message