The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.
The most common authentication scheme is the “Basic” authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:
Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.”
The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer <token>
The Bearer authentication scheme was originally created as part of OAuth 2.0 in RFC 6750, but is sometimes also used on its own.
Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL).
Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header that contains the word Basic word followed by a space and a base64-encoded string username:password. For example, to authorize as demo / p@55w0rd the client would send:
A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
The Bearer Token or Refresh token is created for you by the Authentication server. When a user authenticates your application (client) the authentication server then goes and generates for you a Bearer Token (refresh token) which you can then use to get an Access Token.
The Bearer Token is normally some kind of secret value created by the authentication server. It isn’t random; it is created based upon the user giving you access and the client your application getting access.
In order to access an API for example you need to use an Access Token. Access tokens are short lived (around an hour). You use the bearer token to get a new Access token. To get an access token you send the Authentication server this bearer token along with your client id. This way the server knows that the application using the bearer token is the same application that the bearer token was created for. Example: I can’t just take a bearer token created for your application and use it with my application it wont work because it wasn’t generated for me.
Google Refresh token looks something like this: 1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
copied from comment: I don’t think there are any restrictions on the bearer tokens you supply. Only thing I can think of is that its nice to allow more then one. For example a user can authenticate the application up to 30 times and the old bearer tokens will still work. oh and if one hasn’t been used for say 6 months I would remove it from your system. It’s your authentication server that will have to generate them and validate them so how it’s formatted is up to you.
The authorization server MAY support any suitable HTTP authentication scheme matching its security requirements. When using other authentication methods, the authorization server MUST define a mapping between the client identifier (registration record) and authentication scheme.
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.8.1
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks
[preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.09.0-ce. Max validated version: 17.03
[preflight] Starting the kubelet service
[kubeadm] WARNING: starting in1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [localhost.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.119220.127.116.11]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in"/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] This often takes around a minute; or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 29.502147 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config"in the "kube-system" Namespace
[markmaster] Will mark node localhost.localdomain as master by adding a label and a taint
[markmaster] Master localhost.localdomain tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: 405cea.cb350fd16023e08d
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run (as a regular user):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
656dbe0d38be gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_kube-dns-545bc4bfd4-2wrrg_kube-system_de9494c2-b6f7-11e7-af7d-0800278919d4_0
e0dfea9f00a5 gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_kube-proxy-fnj6t_kube-system_de803e34-b6f7-11e7-af7d-0800278919d4_0
da7a7ec9d578 mirrorgooglecontainers/kube-scheduler-amd64 "kube-scheduler --..."2 minutes ago Up 2 minutes k8s_kube-scheduler_kube-scheduler-localhost.localdomain_kube-system_5fbf3e68ff1f2f57797628887e9c1bec_0
2126fd5a0d57 mirrorgooglecontainers/kube-controller-manager-amd64 "kube-controller-m..."2 minutes ago Up 2 minutes k8s_kube-controller-manager_kube-controller-manager-localhost.localdomain_kube-system_2f2bd9f6dddf513ac6c21a43335777dd_0
21edd6e71eeb mirrorgooglecontainers/kube-apiserver-amd64 "kube-apiserver --..."2 minutes ago Up 2 minutes k8s_kube-apiserver_kube-apiserver-localhost.localdomain_kube-system_dc78e47f78457da950a93b36ff6ac4ba_0
8712a0e9833f mirrorgooglecontainers/etcd-amd64 "etcd --listen-cli..."2 minutes ago Up 2 minutes k8s_etcd_etcd-localhost.localdomain_kube-system_d76e26fba3bf2bfd215eb29011d55250_0
47bd69d72e16 gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_kube-controller-manager-localhost.localdomain_kube-system_2f2bd9f6dddf513ac6c21a43335777dd_0
292d54bd936f gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_kube-apiserver-localhost.localdomain_kube-system_dc78e47f78457da950a93b36ff6ac4ba_0
dae95c5d2a8f gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_kube-scheduler-localhost.localdomain_kube-system_5fbf3e68ff1f2f57797628887e9c1bec_0
5d41a042874c gcr.io/google_containers/pause-amd64:3.0"/pause"2 minutes ago Up 2 minutes k8s_POD_etcd-localhost.localdomain_kube-system_d76e26fba3bf2bfd215eb29011d55250_0