The RFC6750 does define 3 options for encoding the bearer token in the HTTP request: https://tools.ietf.org/html/rfc6750 2.1. Authorization Request Header Field Example: GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM 2.2. Form-Encoded Body Parameter Example: POST /resource HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded access_token=mF_9.B5f-4.1JqM 2.3. URI Query Parameter Example: GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1 Host: server.example.com Given that the OIDC token (encoded as a JWT) can be large, especially if the group claim is added, I thought the best option would be 2.1 as some HTTP servers have issues with very long URI's. None of these options seem to patch what GlobalProtect is doing though. Regards, Alan Jowett -----Original Message----- From: Daniel Lenski <dlenski@xxxxxxxxx> Sent: Sunday, January 26, 2020 11:38 PM To: David Woodhouse <dwmw2@xxxxxxxxxxxxx> Cc: Alan Jowett <Alan.Jowett@xxxxxxxxxxxxx>; openconnect-devel@xxxxxxxxxxxxxxxxxxx Subject: [EXTERNAL] Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel. On Wed, 2020-01-22 at 20:05 +0000, Alan Jowett wrote: > OpenConnect folks, > > Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel. > > Background: > My team is working on a feature to support using OpenID Connect tokens > (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fope > nid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CAlan > .Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf8 > 6f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&sdata=uB5EMEnIrkZ%2BTYzpqA4H0Y%2B4y7grtpEpOF9QZvaocQs%3D&reserved=0) to authenticate and authorize clients connecting to an OpenConnect server. There are growing list of OpenID Connect providers that this should work with, making this change fairly broadly applicable. Looks like Alan added an issue here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fopenconnect%2Fopenconnect%2Fissues%2F99&data=02%7C01%7CAlan.Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&sdata=p%2FdLROYhz9B9lZt3uGqNgzSsGZ2uTV8KczHqXxqdtyE%3D&reserved=0 I'll point out that this is in some ways similar to the "alternative secret" junk that I have to do for GlobalProtect+SAML to work. What the two have in common is that authentication uses some alternative cookie field instead of the usual password field — and this field can't be autodetected from the "normal" authentication forms sent by the server. If I've got that right, then hopefully we can unify the API for these "alternative secrets". What we're currently doing with GP+SAML is jamming ":ALT_SECRET_FIELD" onto the end of the URL path, and parsing it out from there: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fopenconnect%2Fopenconnect%2Fblob%2Fmaster%2Fauth-globalprotect.c%23L573-582&data=02%7C01%7CAlan.Jowett%40microsoft.com%7Cc2723a399d0744cbef1f08d7a2f39054%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637157039293873057&sdata=9SZYL4K9GWUj1XhX%2F0VjPdWtKgwqDLT83S%2F9nFYt66I%3D&reserved=0 That's fairly horrid… it'd be good to have a uniform mechanism to specify this via the command-line AND the libopenconnect API. -Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
