oauth - OAuth2 returning JWT in place of access_token -

oauth - OAuth2 returning JWT in place of access_token -

i in process of building oauth2 provider using bshaffer php library here.

i've found ietf draft specifications outline implementations phone call out usage of json web tokens authorization grant , client authentication.

the implementation interests me returning jwt in place of regular access token, seen here. in case of dead link, access token response pasted below.

{ "access_token":"eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyjpzci6ijyzmjiwnzg0yzuzoda3zjvmztc2yjg4zjzknjdlmmexztixodlhzteilcjjbgllbnrfawqioijuzxn0iensawvudcbjrcisinvzzxjfawqiom51bgwsimv4cglyzxmiojezodawndq1ndisinrva2vux3r5cguioijizwfyzxiilcjzy29wzsi6bnvsbh0.pcc4k8q_etpu-j4ygfeubudeymjhtpzfkvq__sxpe78esi7xtniqootgfwa62y4sj5npta8xpudglh8fueh_apzx4wgcire1p4nt4apqcotbgcucnxwjmp8znk9f76id2wxthambmpsttekuyyuyqkccdxlicsbvvclzugkz6-g", "client_id":"client_id", "user_id":null, "expires":1382630473, "scope":null }

it returns jwt in place of regularly generated access token normal authorization grants. client , user credentials grants more of import me dealing in 1st party api access.

this implementation seems ideal, because not need maintain store of generated tokens, limiting amount of infrastructure required. @ point if open api third-parties need key-store various pub/priv keys validate each client's tokens, , limit risk if nefarious party stole encryption key.

i sense implementation relying on asymmetric encryption , ssl/tls. there potential security risks i've missed?

the signature on jwt protect claims inside token tampering, cannot protect claims external token. therefore, expires field in construction not protected , can tampered with.

to protect tampering, want utilize exp claim.

two valid solutions are:

double check expires against exp drop expires , utilize exp

you might prefer 1 on other depending on requirements. personally, i'd maintain simple , go (2)

oauth oauth-2.0 jwt