Re: Bearer Tokens in URLs

I think my use case may not have been clear.

Let's assume I have an endpoint that is accessed via Bearer token.
I am storing the endpoint URL and token in a config file for a client that
must access the service.
Using JSON as an example

I can either store:
"config" : "https://:secrettoken@example.com/api"

or

"config" : {
 "endpoint": "https://example.com/api",
 "token": "secrettolen"
}

The former seems like a neat way to do this and establish a convention that
would work across languages and clients and not be bound to a config data
model.
(Database connection strings which have adopted URI's as a convention in
many cases, is a similar use case)

As I noted before the convention is for an HTTP client that is passed the
following URL:

https://user:pass@example.com/api

to make an HTTP request to https://example.com/api using BASE64(user:pass@)
as in the Authorization header as "Basic BASE64(user:pass@)".

Restating my question, given the prevalence use of Bearer tokens these days
would it makes sense to establish a convention of assuming that a
username:password where the username is empty is intended to be used as a
Bearer token as opposed to a Basic auth credential or is the storing of
Basic auth credentials in the URl geenrally considered a bad idea these
days so it's a bad example to copy?

On Sun, 8 Sep 2019 at 10:11, Graham Klyne <gk@ninebynine.org> wrote:

> I'd say this could be problematic.  E.g., see:
>
> https://www.w3.org/TR/capability-urls/#advantages
> https://stackoverflow.com/questions/4833314/are-secret-urls-truly-secure
>
> (and other responses to googling "secrets in urls").
>
> #g
> --
>
>
>
> On 06/09/2019 16:53, Adrian Hope-Bailie wrote:
> > Does anyone know of a specification or documented convention for
> providing a
> > bearer token in a URL?
> >
> > I.e. There are a number of HTTP clients that will interpret userinfo in
> a URL as
> > being the value to send in an HTTP Authorization header using Basic auth.
> >
> > I assume this is a peculiarity of HTTP and I note the username:password
> form is
> > deprecated in RFC3986.
> >
> > Does a convention of https://:<token>@host make sense?
> > ie. empty username and token SHOULD never be displayed in the clear
> because it
> > is after the colon.
> >
> > The use case here is providing, for example, a callback URL that is
> secured
> > using a bearer token.
> > Or storing the URL in config in a form that is easily serialized to a
> string
> > without needing to define an encoding and format etc.
>
>